-
Notifications
You must be signed in to change notification settings - Fork 3
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
Write TPW variables into a new file every timestep #9
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hollyhan , thanks for describing these changes so carefully. I made one comment that you may want to address or not, but I'm otherwise happy for you to proceed with merging when you're ready.
@@ -1296,6 +1273,20 @@ subroutine sl_solver(itersl, iter, dtime, starttime, mali_iceload, mali_mask, sl | |||
write(201,'(I4)') nmelt | |||
close(201) | |||
|
|||
! number of iteration it takes for the inner convergence | |||
open(unit = 201, file = trim(outputfolder)//'numiter', form = 'formatted', access ='sequential', & | |||
& status = 'old', position='append') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this file have the same issue - that if a restart causes some time steps to be rerun there will be multiple copies of those lines? Maybe that doesn't matter much for this file but wanted to point it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matthewhoffman
Yes - this file will have the same issue, along with other files like times
as well. These two files won't affect the SLM calculation itself but affect post-processing if used. But those files are rarely used nor looked at. So maybe I can either just stop writing those into a file in the first place, or we just keep it as is for now and address this issue in a new PR. The new PR could be even on making all the I/O to happen in the netcdf-format (because it's been proven that the text-formatted files take up way too much space (as we've recently seen in my project directory on Chicoma), and the remaining issue will be automatically taken care of. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with that limitation with this file for now if you are. I don't imagine I will be looking at them, so if you don't think they are critical, that's ok with me.
…Dev/develop Previously, when the regional sea-level prediction capability was added to MALI (#21), the restart config option for the sea-level model was not added. This led the sea-level model to get initialized to Timestep zero when coupled MALI-SLM simulations are being restarted, forgetting about the ice loading changes and associated viscoelastic solid earth deformation that happened in the timesteps prior to current model time. This PR fixes the problem by allowing the sea-level model to resume where it was left off. Note in parallel to this PR, the version of the SLM needs to incorporate the changes made in the following accompanying PR (MALI-Dev/1DSeaLevelModel_FWTW#9) * hollyhan/add_restart_functionality_slm: Don't call SLM on init of a restart Add addl info on restart about the calculated time since last SLM call Allow restarts at any interval when using SLM Add missing error flag so model actually dies when error occurs Add missing arguments to log write statement Update restart check to also use time interval division Adjust check if adaptive dt is on or not Update checks using interval division Improve error handling, correct other usage of config_uplift_method Improve synchronization of timesteps between MALI and SLM Add restart option when the SLM is coupled to MALI
Previously, the sea-level model variables related to true polar wander (TPW) at every time step were written out to a single text file. While this way poses no problem and makes the output folder less crowded, it is problematic when simulations have to be restarted in the middle of run because the variables are appended to the existing file rather than replacing the lines that have been written previously. For example, if a run dies at timestep 5 and gets restarted at timestep 3, the TPW variables calculated at timestep 3 in the restart run will be appended to the TPW variables at timestep 4 written from the previous run before it died. Unfortunately, Fortran doesn't allow overwriting specific lines of files in its sequential file I/O functionality, and the most straightforward & easiest solution is to write a new file for the TPW variables at every single timestep such the new file replaces the old file if it exists.
Below is the testing result on Chicoma (/lustre/scratch4/turquoise/hollyhan/compass/MALI-Dev/components/mpas-albany-landice/src/SeaLevelModel)
Inputs: cylindrical ice sheet retreating at rate of 1 km/yr
length of simulation: 4 years for every 1 year time interval (i.e. 4 timesteps)
TPW file indicating TPW variables at each timestep (0,1,2,3,4) using the original code before the changes in this PR:
(Note: each block of outputs represent the TPW values at each timestep)
Example visualization: changes in the gravitational field at timestep 4
TPW# file at timestep 1 and 4 using the code in this PR:
Example visualization: changes in the gravitational field at timestep 4
Difference in the
G
field (original code result minus the modified code result):