search

E3SM-Project / ACME-ECP

E3SM MMF for DoE ECP project
Other
9 stars 1 forks source link

Add the MAML configuration to the E3SM-MMF #105

Closed guangxinglin closed 4 years ago

guangxinglin commented 4 years ago

This branch implemented the Multiple Atmosphere Multiple Land (MAML) option to the E3SM-MMF. Below briefly describes what were changed in the code.

  1. Add "use_MAML" in the namelist to turn on the MAML option. All changed codes are controlled by "#ifdef MAML" conditional compilation statement.

  2. Enable the E3SM to run multiple land instances simultaneously (the number of land instances are equal to the atmosphere CRM columns), but to run only one atmosphere instance (because the EAM already has multiple CRM columns).

    1. Chang the cam_in and cam_out fluxes from the GCM-level to CRM-level fluxes. Make sure that each atmosphere CRM column outputs its own surface fluxes to the corresponding land instance.

  3. Average the cam_in fluxes (the surface fluxes from land to atmosphere) over the multiple land instances when applied to the atmosphere model, because in the current MMF setup, surface fluxes are applied to each atmosphere GCM grids, rather than to each CRM column.

I also did the e3sm_ecp test runs. All passed except for the NML

[NML]

whannah1 commented 4 years ago

So I've been thinking about how the way MAML is controlled with #ifdefs, and it presents a tricky issue. I understand it was done because of the variables that need to have an extra dimension. Without the #ifdef approach we would likely see horrendous merge conflicts every time we merge with E3SM, but that also means any change to those areas might need to be fixed/updated manually to be consistent with the non-MAML simulations. So both scenarios seem potentially bad. Ben brought up using a "packing" strategy similar to what he has done with RRTMGP that would allow us to not add the extra dimension, but while this may cause less conflicts, I think we would essentially have a similar issue.

It seems the "right" way to do this would be to submit a PR to E3SM that promotes these variables to have an extra dimension, and then pull it down into ECP so that future merge conflicts are reduced. There's probably a case to be made that this framework could be used with the subcolumn infrastructure, so it wouldn't be totally useless to E3SM. I realize that would mean a lot of work and delay, but it seems like a good strategy. I wish we had thought about this in the beginning.

guangxinglin commented 4 years ago

Walter,

Thanks for bringing this. It is a great suggestion if the E3SM would use the subcolumn infrastructure by adding an extra dimension. In the same time, that would also need a lot of efforts and delay. Without further delay, I think we should keep the current #ifdefs as a temporary solution and go ahead to test the MAML runs and start to look at some science there. In the long-run, I agree we need to submit a PR to E3SM.

On Fri, Sep 20, 2019 at 7:53 AM Walter Hannah notifications@github.com wrote:

So I've been thinking about how the way MAML is controlled with #ifdefs, and it presents a tricky issue. I understand it was done because of the variables that need to have an extra dimension. Without the #ifdef approach we would likely see horrendous merge conflicts every time we merge with E3SM, but that also means any change to those areas might need to be fixed/updated manually to be consistent with the non-MAML simulations. So both scenarios seem potentially bad. Ben brought up using a "packing" strategy similar to what he has done with RRTMGP that would allow us to not add the extra dimension, but while this may cause less conflicts, I think we would essentially have a similar issue.

It seems the "right" way to do this would be to submit a PR to E3SM that promotes these variables to have an extra dimension, and then pull it down into ECP so that future merge conflicts are reduced. There's probably a case to be made that this framework could be used with the subcolumn infrastructure, so it wouldn't be totally useless to E3SM. I realize that would mean a lot of work and delay, but it seems like a good strategy. I wish we had thought about this in the beginning.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/E3SM-Project/ACME-ECP/pull/105?email_source=notifications&email_token=AGE4GNBLKCX3Z76PGYY5FQLQKTPXBA5CNFSM4IYFAABKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7G6HIY#issuecomment-533586851, or mute the thread https://github.com/notifications/unsubscribe-auth/AGE4GNGGTYELE44QUCLRRVLQKTPXBANCNFSM4IYFAABA .