Skip to content

More consistent allocation of variables #68

Open

Description

@ClemensSchannwell

I have come across the following issue that I may have introduced myself. Maybe (or most likely) it is because a lack of understanding on my side. So at the moment I believe what we make EBFM do is that it takes the ELMER mesh and assumes that each of the gridpoints needs a value for temperature and surface mass balance. I am fine with that assumption, because we could in theory build a glacier where we currently have no ice. However, I believe that EBFM also needs an ice mask which is a mask that delineates where we actually have ice surfaces. I thought that the variable grid["mask"] is used for that, but whenever I have fewer points in the array grid["mask"] then total gridpoints, there are a bunch of dimension mismatches. So my hunch is that we allocate certain variables based on the number of total gridpoints and certain variables on the number of ice-covered gridpoints. I think what should be done is that all variables are allocated based on the number of total gridpoints and then the approporiate ice-covered gridpoints are filled/marked accordingly.

To make this more concrete, at the moment we use the variable gpsum to allocate variables such as OUT["subW"]. But the variable gpsum is the number of glacier cells. In my view, this can be quite confusing. More critically, the model would fail immediately if gpsum < total number of gridpoints, for example in these lines here: https://github.com/EBFMorg/EBFM/blob/ElmerXIOSrun-patch-1/src/ebfm/INIT.py#L443C1-L450C74, because mask_indices[0] contains indices that go beyond the length of OUT["subW"]. Maybe @wardvp know how best to do this or if I am misunderstanding something...

Activity

  1. BenjaminRodenberg commented on Jan 19, 2026

    @BenjaminRodenberg
    Collaborator

    I had to revert some changes in #53 that are related to the computation of gpsum. This should give a good idea where to begin when working on this issue.

  2. added this to the v0.3.0 milestone on Jan 19, 2026
  3. removed this from the v0.3.0 milestone on Mar 18, 2026
  4. BenjaminRodenberg commented on Mar 18, 2026

    @BenjaminRodenberg
    Collaborator

    Removed the milestone because this issue is relatively open-ended. Still I think it's a good reminder for a very useful refactoring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestquestionFurther information is requested

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions