Update particles_run call to allow accurate particle advection using … #785
Conversation
|
I think that I understand where you are going with this PR, and I am convinced that it is correct. However, we have a problem here with how to manage changing the interfaces between two pieces of code that are managed under separate version controlled repositories. We try to never change two repositories at once, and we don't want to do anything that forces people to change their answers or stop using updated versions of MOM6 without a lot of previous coordination and communication. We have this same situation of evolving shared interfaces between SIS2 and MOM6 and between FMS and MOM6, so we do have some experience dealing with this situation. One option is to use coordinated changes to optional arguments to ensure that the is are a pair of intermediate states, for which one code (e.g., SIS2) can work with two versions of the other (e.g., MOM6), and then we do update so that two successive versions of the first code (e.g., SIS2) can work with the same version of the other. The other option is to actually have two distinct interfaces to the external code in different directories, but the rest of the MOM6 code uses the same interface. This is the approach that we took with config_src/infra/FMS1/ and config_src/infra/FMS2/. Let's arrange a time for a virtual discussion to sort through our options for the best way to handle this case. |
|
To the best of my knowledge, the only person using this code is Niki Zadeh, and I suspect he is using the version of the code that includes this PR. If he is ok with it, I think we should be able to merge these changes without disrupting anyone's workflow. |
|
No worries, I'ld be happy using the new interface when it becomes available. Thanks. |
|
With this explicit confirmation that we are very unlikely to that anyone is already using the older version of the particles code in a way that would disrupt their work if we accepted these interfaces, I think that we can accept them without further changes. |
There was a problem hiding this comment.
Although this is a change to an external interface, it appears that it is not yet being used widely enough that this change would disrupt any on-going work. We can therefore accept these interfaces changes as is without going through the extra steps to ensure graceful backward compatibility.
…u, v or uh, vh The drifters package is able to run in 2 different modes: one where the particles are advected using u and v, and one where they are advected using uh and vh. When u and v are used (i.e. the drifters are advected using the resolved velocities only, with no sub-grd component), the particles package needs the layer thickness that is consistent with these velocities, so particles_run needs to be called before any subgrid scale parameterizations are applied. This was not implemented correctly in my last PR, and is corrected here. The particles package also needs the correct timestep for particle advection. This is added here.
Hallberg-NOAA
force-pushed
the
particles-uh
branch
from
7295f7e to
ced28a3
Compare
|
This PR has passed pipeline testing at https://gitlab.gfdl.noaa.gov/ogrp/mom6ci/MOM6/-/pipelines/26082. |
…u, v or uh, vh
The drifters package is able to run in 2 different modes: one where the particles are advected using u and v, and one where they are advected using uh and vh. When u and v are used (i.e. the drifters are advected using the resolved velocities only, with no sub-grd component), the particles package needs the layer thickness that is consistent with these velocities, so particles_run needs to be called before any subgrid scale parameterizations are applied. This was not implemented correctly in my last PR, and is corrected here.
The particles package also needs the correct timestep for particle advection. This is added here.