search

ESCOMP / CISM

Community Ice Sheet Model
GNU Lesser General Public License v3.0
6 stars 11 forks source link

time dependent forcing applied at incorrect time in timestep #7

Open billsacks opened 6 years ago

billsacks commented 6 years ago

From @stephenprice on March 10, 2015 18:17

In cism_driver/cism_front_end.F90, we have the option to read time dependent forcing fields from an input .nc file. Currently, we use this to read in an apply temperature, smb, and Dirichlet BC info (mask for where Dirichlet BCs are to be applied as well as the u and v vel fields to apply there). This capability is demonstrated in one supported test case (see ./tests/higher-order/dome/dome.forcing.*).

We found, however, that for implementing Dirichlet boundaries the u and v fields need to be applied at the start of the time step, whereas the smb and temperature should be applied at the end of the time step. The current implementation only allows for one choice (all fields are read in and applied at the same time).

Right now, the problems that arise from this inconsistency are worse if we leave the forcing at the end of the time step as opposed to moving it to the start of the time step (we can't make progress on simulations with time dependent vel BCs applied, a priority for validation), so we will move it to the start. Thus, the smb and sfc air temps are being applied as bcs / source terms at the wrong part of the time step. This can / should eventually be fixed by allowing for different forcing fields to be applied at different parts of the time step.

Copied from original issue: E3SM-Project/cism-piscees#19

billsacks commented 6 years ago

From @stephenprice on March 10, 2015 18:17

@matthewhoffman please look over my description here and edit it as necessary.

billsacks commented 6 years ago

From @matthewhoffman on March 11, 2015 2:54

@stephenprice , this looks good. I'll add that the problem with velocity when reading forcing at the end of the time step is that the velocity field that was read from file clobbers the velocity field that was calculated by the model - which clearly is bad. :-1:

Another thought just crossed my mind - if the velocity values used by kinbcmask were in a different field (e.g., kinbcuvel, kinbcvvel), I think that would solve the problem and allow the values to be read at the end of the timestep - and more easily than other potential fixes. One thing to consider is that right now Glissade is only using a 2d field of values for the kinbc (it applies the basal uvel/vvel values throughout the entire column at every grid point that is masked) - so if we added new fields for the kinbc values, they would only need to be 2d fields (at least for now). We should give more careful thought to this potential solution when the time comes to address this.