Project

General

Profile

Feature #23221

Remapping of M7 dry/wet radii from restart file missing

Added by Andreas Hilboll 6 months ago. Updated 6 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11/27/2019
Due date:
% Done:

10%


Description

With an up-to-date trunk, we cannot restart using remap with CB05 any more.

The problem is caused by commit 1005 (https://dev.knmi.nl/projects/tm5mp/repository/revisions/1005) where "remapping not fully implemented yet for M7 radii" now causes the model to abort.

Previous to this change, we were able to restart with remapping with M7.

So the questions are:

1. Why was this check introduced?
2. Does this mean that all our previous simulations we did with this are wrong?
3. Does this impact the moguntia simulations (currently moguntia uses the CB05 project for restarting code)?

History

#1 Updated by Philippe Le Sager 6 months ago

  • Status changed from New to In Progress

Andreas Hilboll wrote:

1. Why was this check introduced?

As it says, to tell the user that this is not fully implemented. I opted for a fullstop instead of a warning, so the user can decide for himself/herself: fix it or continue as it was done before by commenting the call to abort.

2. Does this mean that all our previous simulations we did with this are wrong?

Hard to tell without knowing what are your simulations and their setup.

3. Does this impact the moguntia simulations (currently moguntia uses the CB05 project for restarting code)?

Not sure. Would have to check when was the last time Stelios branch has been synced with the trunk. Will check as soon as I have access to a terminal (on phone right now)

#2 Updated by Philippe Le Sager 6 months ago

Checking the moguntia branch:

cca-login4 ~/TM5/moguntia 
[4986] >>> svn info
Path: .
Working Copy Root Path: /home/ms/nl/nm6/TM5/moguntia
URL: https://svn.knmi.nl/svn/TM5-MP/branches/moguntia
Relative URL: ^/branches/moguntia
Repository Root: https://svn.knmi.nl/svn/TM5-MP
Repository UUID: 8e22cfa4-a5eb-4c1e-9989-aa572767e595
Revision: 1079
Node Kind: directory
Schedule: normal
Last Changed Author: steliosm
Last Changed Rev: 1078
Last Changed Date: 2019-12-02 09:13:36 +0100 (Mon, 02 Dec 2019)

cca-login4 ~/TM5/moguntia 
[4987] >>> svn mergeinfo ^/trunk
    youngest common ancestor
    |         last full merge
    |         |        tip of branch
    |         |        |         repository path

    783       941      1079    
    |         |        |       
  -------| |------------         trunk
     \         \               
      \         \              
       --| |------------         branches/moguntia
                       |       
                       WC      

cca-login4 ~/TM5/moguntia 
[4988] >>> svn pg svn:mergeinfo | grep trunk
/trunk:784-983
/trunk/proj/cb05/ebischeme.F90:439-672
/trunk/proj/cb05/emission.F90:439-672
/trunk/proj/cb05/emission_read.F90:439-672
/trunk/rc:439-672
and here are the last three synchronizations with the trunk:
[4989] >>> svn log --stop-on-copy | grep -B2 trunk
r984 | steliosm | 2019-04-09 11:36:37 +0200 (Tue, 09 Apr 2019) | 1 line

merged with trunk
--
r912 | sager | 2018-09-26 14:46:17 +0200 (Wed, 26 Sep 2018) | 1 line

[moguntia] sync with trunk (photo94sza, CRESCENDO output fixes, LiNOx tropo fix)
--
r884 | sager | 2018-09-05 10:59:48 +0200 (Wed, 05 Sep 2018) | 1 line

[moguntia] sync with trunk

[....]
So the last sync was done by Stelios beginning of April at r984. That's before r1005, and also before r995, where the mixing ratio from the restart is used in place of the tracer mass when istart=32. The commit r995 makes no difference if the air mass in the restart is closed to the one from ERA-Interim.

#3 Updated by Philippe Le Sager 6 months ago

You need to understand what is happening when reading your restart for a different resolution with istart=32. In the current moguntia (and old trunk), M7 optics fields are read as if they were at the correct resolution. Before and after the scattering of the read data, your target array is either partially filled or overfilled. (MPI calls in Fortran work like in C: you give a start address and fill from there.) The end result depends on the number of cores you are using, but when remapping you need to use a number of cores that divides the number of grid boxes in both resolutions. So you are likely to end up with only zeroes on some tiles when going from a coarser to a finer grid. You can look at it as "put all tracer into a subset of the boxes". Some spinup will alleviate that.

Going from fine to coarse, if it does not crash when reading the data (it should), all boxes will be filled with a subset of the original data. But there is some spilling guaranteed, and you will corrupt your memory without you necessarily noticing.

All this is handled in a better way in the updated version of the code (trunk@1005). But only for the masses. For the dry and wet radii, we need to decide how to remap.

And if you are thinking about using "save file", it is worse: M7 optics fields are ignored altogether.

#4 Updated by Philippe Le Sager 6 months ago

  • Tracker changed from Bug to Feature
  • Subject changed from Cannot restart with remapping with trunk / cb05 to Remapping of M7 dry/wet radii from restart file missing
  • % Done changed from 0 to 10

Small edit to post #23221-1 above, and a new title.

Also available in: Atom PDF