Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow individual glaciers to merge together #624

Merged
merged 14 commits into from Dec 20, 2018

Conversation

Projects
None yet
3 participants
@matthiasdusch
Copy link
Member

matthiasdusch commented Dec 10, 2018

This is the same as #600. I made some awful merge/commit errors there. Opening a new PR seemed cleaner and easier.

  • Tests added/passed
  • Fully documented
  • Entry in whats-new.rst
  • Write a new GlacierDirectory for merged glaciers
  • Come up with a smarter solution how to (efficiently) handle the climate files
  • Write a function gis.merged_glacier_masks to provide necessary geometry files for graphics
  • Write a workflow-function to easily process a set of glaciers and tributaries

OGGM glaciers are initialised with current (~2003) glacier geometry and modeled as entities. For all scenarios with glacier retreat or only small advances this is perfectly fine. But for simulations where glaciers advance significantly nearby glaciers might merge together and behave different then when modeled individually.
The first requirement to tackle this issue was solved with #539, as each Flowline got an individual mu*.

This Pull Request will most likely only deal with individual glaciers and their tributary glaciers. Future work could adapt this approach and apply it to regional scales. But I doubt merging glaciers will ever become a fully automated process within all OGGM simulations. More likely merging glaciers will be a deliberate choice for specific simulations.

In this 1. commit I provide two new functions:
intersect_downstream_lines finds tributary glaciers to a main glacier by intersecting downstream lines. This will separate true tributaries from ones flowing into other valleys.
merge_tributary_flowlines will merge the model_flowlines of the tributary glaciers with the ones of the main glacier. The result is one glacier containing all tributary flowlines.

One necessary addition in the process was to add a Centerline.climatefile attribute. This allows to use a different climate file for each individual flowline, as tributary glaciers might likely use a different climate reference file than the main glacier one.

This PR is still work in progress. I at least want to add a more automatic selection of possible tributary glaciers. But I am happy to take comments or suggestions!


For illustration a simulation with artificial climate around Hintereisferner: For the first run all 5 pictured glaciers (Hintereisferner, two small previously connected pieces, Kesselwandferner in the north and Hochjochferner in the east) are modeled in basic OGGM fashion as entities.

The second plot shows a merged run, where all flowlines of the other 4 glaciers are merged to Hintereisferner.
Note how the upper part of the glaciers are identical in depth and width, but the lower part of the merged glacier is thicker, wider and further advanced as there is now more mass contributing to it.

individual_hef

merged_hef


I think the last two things to do are

  • write a small function gis.merged_glacier_masks, adapted from the original glacier_masks which provides glacier outlines to the graphics functions. For this I need to merge the outlines of the tributary glaciers and combine them in one shp-file.
  • write a workflow-function which takes a list of glaciers and a list of possible tributary glaciers and returns the merged glaciers
@pep8speaks

This comment has been minimized.

Copy link

pep8speaks commented Dec 10, 2018

Hello @matthiasdusch! Thanks for updating the PR.

Comment last updated on December 19, 2018 at 16:19 Hours UTC
@fmaussion
Copy link
Member

fmaussion left a comment

Thanks a lot for this, this is looking great and I like the approach! This is nice looking code 😍

I have the feeling some parts could be simplified, but I don't think it's necessary for now: if it works, that good! Please double check the docstrings and the part about the possible duplication in code again.

I'm sorry I created a conflict again, hopefully this can be solved online this time. Let me know before you want to merge, I might have another look.

Show resolved Hide resolved oggm/core/centerlines.py Outdated
Show resolved Hide resolved oggm/core/flowline.py
Show resolved Hide resolved oggm/core/flowline.py Outdated
Show resolved Hide resolved oggm/core/flowline.py Outdated
Show resolved Hide resolved oggm/core/flowline.py
tfl.dx_meter = tfl.map_dx * tfl.dx

if nr == 0:
# change the array size of tributary main flowline attributs

This comment has been minimized.

Copy link
@fmaussion

fmaussion Dec 17, 2018

Member

When I see this, I wonder if it was easier to instantiate a new Centerline object instead of muting the original one. I'm not as deep into it as you, though, so maybe there are complications I didn't think of

This comment has been minimized.

Copy link
@matthiasdusch

matthiasdusch Dec 18, 2018

Author Member

Well I agree mutilating the existing Centerline is not very pretty.
But to initialize a new one, I think we would either have to use some manipulated glacier geometries or copy, adapt and redo the whole centerline processes. Both seems more error prone to me than cutting the line where we know it was initialized for a working glacier.

But I am happy to discuss and change this later on.

This comment has been minimized.

Copy link
@fmaussion

fmaussion Dec 18, 2018

Member

I trust your judgement here!

Show resolved Hide resolved oggm/utils/_workflow.py Outdated
Show resolved Hide resolved oggm/utils/_workflow.py Outdated
Show resolved Hide resolved oggm/utils/_workflow.py
Show resolved Hide resolved oggm/utils/_workflow.py

matthiasdusch added some commits Dec 17, 2018

@fmaussion
Copy link
Member

fmaussion left a comment

This is a great addition, thanks a lot! Also, very nice code ;-)

I still have a few comments regarding the workflow but feel free to merge as is, we might revisit in the next year (or not), when we freeze v1.1

Show resolved Hide resolved oggm/core/flowline.py Outdated
years = 200 # arbitrary
y0 = 1950 # arbitrary
tbias = -1.0 # arbitrary
mbbias = 0.0 # necessary?

This comment has been minimized.

Copy link
@fmaussion

fmaussion Dec 20, 2018

Member

necessary only if you want the MB at t* , i.e. a balanced MB

This comment has been minimized.

Copy link
@matthiasdusch

matthiasdusch Dec 20, 2018

Author Member

When I wrote this, I wasn't sure how to handle the MB calibration bias and have since then forgotten about it....
I now implemented the local_mustar files to be copied to the merged GDir. MultipleFlowlineMB can now use a different bias for each flowline if they originate from different glaciers.

# preprocess the main glaciers to the end
climate_tasks(gdirs_main)
inversion_tasks(gdirs_main)
execute_entity_task(tasks.init_present_time_glacier, gdirs_main)

This comment has been minimized.

Copy link
@fmaussion

fmaussion Dec 20, 2018

Member

Intuitively I wouldn't (re)do all the preprocessing tasks here. I thought the workflow would be: 1 prepro some glaciers, 2 merge them, 3 run the merge simulation. This task should start at step 2 and assume the glaciers are preprocessed already.

(note that it's also because of my recent developments which allow to start from a pre-processed state, which will become the default workflow for most users)

This comment has been minimized.

Copy link
@matthiasdusch

matthiasdusch Dec 20, 2018

Author Member

Yes, my initial idea was to only preprocess the none relevant glacieres as far as neccessary. Purely with performance in mind.

But I agree, this bloats the workflow function. I changed this. For the unlikely case one runs into performance problems because of this, it's easier to write a dedicated workflow.

# preprocess the tributaries to the end
climate_tasks(gdirs_tribs)
inversion_tasks(gdirs_tribs)
execute_entity_task(tasks.init_present_time_glacier, gdirs_tribs)

This comment has been minimized.

Copy link
@fmaussion

fmaussion Dec 20, 2018

Member

I guess you are doing this to preprocess only the glaciers you really need. I can see why this is useful, but it feels quite redundant.

@matthiasdusch matthiasdusch merged commit b301776 into OGGM:master Dec 20, 2018

1 of 2 checks passed

coverage/coveralls Coverage decreased (-4.04%) to 81.302%
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@matthiasdusch matthiasdusch deleted the matthiasdusch:growing_glaciers_3 branch Dec 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.