You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
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.
Activity
BenjaminRodenberg commentedon Jan 19, 2026
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.BenjaminRodenberg commentedon Mar 18, 2026
Removed the milestone because this issue is relatively open-ended. Still I think it's a good reminder for a very useful refactoring.