search

MESH-Model / MESH-Dev

This repository contains the official MESH development code, which is the basis for the 'tags' listed under the MESH-Releases repository. The same tags are listed under this repository. Legacy branches and utilities have also been ported from the former SVN (Subversion) repository. Future developments must create 'forks' from this repository.
Other
2 stars 3 forks source link

IPCP clarification #45

Closed mee067 closed 1 month ago

mee067 commented 4 months ago

What happens when IPCP = 4 without providing rain and snow files? Does that depend on whether MountainMESH (MM) is active or not?

I learnt from Zel that IPCP has to be set to 4 for MM phase adjustment (The psychrometric method of Harder and Pomeroy, 2013) to work (setting iphase=1).

From sequence of calls when running on tiles, MM is called first to adjust the forcing before CLASS is called. The CLASS call includes a call to CLASSI which will partition P into rain and snow for IPCP =1, 2, 3. For IPCP4 is does not do partitioning. It is not clear what it will do if snow and rain are not given. If IPCP=1, 2, or 3, does this override the adjustments made by MM?

dprincz commented 1 month ago

If IPCP is 4 and no source for rain/snow is provided (either from MMESH or input files), the model won't see any precip.

If IPCP is 1, 2 or 3 and MMESH doesn't update the total precip variable, partitioned precip will be overwritten with total precipitation read from file. I think this is documented and why it's required to have IPCP 4 to preserve precipitation adjustments from MMESH.

mee067 commented 1 month ago

IPCP 4 has a different meaning when MMESH is active, it uses the psychrometric calculations of Harder and Pomeroy (2013) in that case. We need to:

  1. unify IPCP flags irrespective of MMESH being active or not
  2. be able to use the psychrometric calculations of Harder and Pomeroy (2013) even if MMESH is inactive

I think @fuadyassin had done something in that direction. Zel should be involved. Couldn't tag him in this Github thread. I can see some potential issues with all the overriding stuff and the sequence of calls.

mee067 commented 1 month ago

I suggest that IPCP 0 means providing rain and snow separately and it should give a warning if either one is missing, or even stop. Running without P is nonsense.

Then IPCP 4 will mean using the psychrometric calculations which should be outside MMESH, or maybe duplicated outside it. MMESH does things at the tile level not the grid level like normal MESH. We need to look into it.

fuadyassin commented 1 month ago

In MMESH, psychrometric calculations by Harder and Pomeroy (2013) were not part of the CLASSI IPCP choice at the time I implemented it in my version back in 2022. I implemented it with IPCP 5 as shown in the attachment CLASSI.txt

mee067 commented 1 month ago

OK Fuad, if your changes are merged with Zel's MMESH ones at some point, we may need to rethink it to avoid code duplication.

This ties in with the restoration of P components in the output. We need to be able to see those.