Skip to content
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

Questions about Horizontal Flux Regridder for GCHP mass flux #3093

Open
yuanjianz opened this issue Oct 11, 2024 · 5 comments
Open

Questions about Horizontal Flux Regridder for GCHP mass flux #3093

yuanjianz opened this issue Oct 11, 2024 · 5 comments
Assignees
Labels
❓ Question Further information is requested

Comments

@yuanjianz
Copy link

yuanjianz commented Oct 11, 2024

Hi all,

I have several questions regarding the horizontal flux regridder and its fix #2056.

Currently variables using HFLUX regridder in GCHP are mass fluxes MFX/Y and courant number CX/Y.

MFXC;MFYC Pa_m+2_s-1 N H F0;003000 none  0.6666666 MFXC;MFYC 
CXC;CYC   1          N H F0;003000 none  none      CX;CY     

MFX/Y

As mentioned in GEOS-ESM/FVdycoreCubed_GridComp#174, GEOS archived MFX/Y are in Pa m+2 = kg * g. Another evidence is in FV3 fv_tp_2d, it seems mfx/y does not need to multiply by edge length to be used.

Also in GEOS-5 file glossary, MFX/Y are already multiplied by edge length:

Thus, isn't it better to rollback to the "before-fix" HFLUX regridder that simply MFX_12 = MFX_1 + MFX_2 instead of the "fixed" version that MFX_12 = (MFX_1*dy_1 + MFX_2*dy_2) / d12? E.g. MFX is uniform 2 kg * g in C180. If regridded to C90, intuitively thinking, 4 kg of air enter the C90 grid. Thus, MFX should be 4 kg * g instead of still being 2 kg * g.

CX/Y

Courant number CX is u*dt/dx if I understand correctly. If the velocity component U is the real "flux" that needs the HFLUX regridder, then CX_12 = [ (CX_1*dx_1) * dy_1 + (CX_2*dx_2) * dy_2 ]/ (dy_12 * dx_12). I am not quite sure about this part, please correct me if I am wrong.

Timestep

Since MFX and CX are both dt dependent, I am curious what's the dynamic heartbeat of GEOS-DAS products like MERRA-2, GEOS-FP and GEOS-IT? Is it 450s like mentioned in GEOS-ESM/FVdycoreCubed_GridComp#174 (comment)? If so, we might be using the wrong scale factor for MFX/Y in GCHP(600s). It should be 1.3333333 instead of 0.6666667. And it help explains why our imported mass flux are always two times smaller than wind derived mass flux.

Tagging @lizziel @sdeastham for GCHP related issues
Tagging @tclune for the Horizontal Flux Regridder implementation

@mathomp4 mathomp4 added the ❓ Question Further information is requested label Oct 11, 2024
@tclune
Copy link
Collaborator

tclune commented Oct 15, 2024

You may well be correct. my memory is that I introduced the weighted sum for MFX/Y at the request of @sdeastham who had some data to indicate that this was needed.

I know that there was some evidence that the units claimed by GEOS were not correct for some associated quantities.

If you have a version that seems to give you good answers, just update this PR and we'll roll it in. GCHP is the only user of the feature - so they are free to define what they need to happen. (Sorry to duck* - I've not given it thought in a long while.)

@yuanjianz
Copy link
Author

Hi @tclune, thanks for the reply. My remaining question is the dynamic timestep of GEOS-FP and GEOS-IT. Many thanks again for your input.

@tclune
Copy link
Collaborator

tclune commented Oct 15, 2024

@bena-nasa @mathomp4 Can you answer the question above from @yuanjianz regarding time step?

@mathomp4
Copy link
Member

I'll check the systems tomorrow on Discover. @mathomp4 A reminder!

@mathomp4
Copy link
Member

@yuanjianz From what I see, both GEOS-FP and GEOS-IT run at a 450 sec heartbeat. Obviously the dynamics might substep, but as far as History would know, it is 450 seconds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
❓ Question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants