Update postprocessed MOC to match analysis member #886
Conversation
|
@vanroekel and @milenaveneziani, could you point me to a simulation where you have computed the MOC using the change in E3SM-Project/E3SM#5170? I would like to compute the MOC with postprocessing for the same simulation and make sure the results are the same, at least to the precision we would expect. |
xylar
force-pushed
the
update_moc_calc
branch
from
66c7d92 to
d8c5ae6
Compare
| mocTop[0, range(1, nz + 1)] = transportZ.cumsum() | ||
| mocTop[0, nz-1:-1:-1] = - transportZ[nz-1:-1:-1].cumsum() |
There was a problem hiding this comment.
@vanroekel and @milenaveneziani, could you double check that this makes the same change as in E3SM-Project/E3SM#5170 (once that gets its indexing fixed)?
The bottom entry of mocTop is purposefully left as all zeros. Then, we sum up (nz-1:-1:-1, meaning from index nz-1 to index 0 in steps of -1, keeping in mind that python has a "stop" index that is beyond the last index, rather than equal to the last index, making things unnecessarily confusing) from the bottom to the top.
There was a problem hiding this comment.
@xylar I compared this form to that in the E3SM PR (with fixed indexing) in a python script I have. the two methods were exactly the same. so this looks good to me.
There was a problem hiding this comment.
approving by visual inspection and testing against the form in E3SM-Project/E3SM#5170
| mocTop[0, range(1, nz + 1)] = transportZ.cumsum() | ||
| mocTop[0, nz-1:-1:-1] = - transportZ[nz-1:-1:-1].cumsum() |
There was a problem hiding this comment.
@xylar I compared this form to that in the E3SM PR (with fixed indexing) in a python script I have. the two methods were exactly the same. so this looks good to me.
|
@vanroekel, once you have the additional 10 years you mentioned in E3SM-Project/E3SM#5170 (comment), I'll run the post-processed MOC on that simulation using this branch and we can compare. Hopefully, the last 10 years look identical or close enough. And we will have a corrected version of the previous 700ish years. |
|
@xylar the new 10 years are here on anvil -- /lcrc/group/e3sm/ac.vanroekel/E3SM_simulations/20220715.submeso.piControl.ne30pg2_EC30to60E2r2.chrysalis/run the new data is years 831-840 |
|
Thanks @vanroekel! |
To match changes made in E3SM in E3SM-Project/E3SM#5170, this merge changes the transport computation into the southern boundary of an MOC region to work from the bottom up rather than the top down.
xylar
force-pushed
the
update_moc_calc
branch
from
d8c5ae6 to
28ebf13
Compare
|
Here are the results of running MPAS-Analysis on Luke's run above from this branch with the MOC analysis member: AM: Post processing: They are similar but there are nontrivial differences. @vanroekel and @milenaveneziani, is this close enough or do you want me to investigate further? Or do we want to rely primarily on the AM anyways and understanding the subtlties of the post-processing tool aren't worth the effort as long as it's pretty close? |
|
These diferences are a little concerning to me. AM: Post processed: |
|
@xylar I agree that the time series differences are bigger than I'm comfortable with. I'll try take another look. |
|
@vanroekel, I'll look into it further. I think the first thing to establish is if the difference is in the southern transect or not. We're not currently storing the time series of the southern transect in the analysis so I'll have to think about how to do this in the simplest way. |
|
Sounds good @xylar let me know if I can help. But one quick thought though. In your post processing AMOC calculation are you including the submesoscale eddy velocity? This would be I ask as the AM does include that impact for this simulation. |
xylar
force-pushed
the
update_moc_calc
branch
2 times, most recently
from
2c25d47 to
87af017
Compare
Instead of just writing out the max AMOC value at RAPID, write out the full AMOC time series.
Similar to the previous commit but for the AM rather than the postprocessed AMOC.
xylar
force-pushed
the
update_moc_calc
branch
from
87af017 to
db16d3b
Compare
|
@vanroekel, oh, thank goodness. I missed your message from earlier. No, the postprocessing script doesn't know abut the I'm also seeing a weird shift in latitude between the AM and postprocessed versions of the MOC. I'll check to see if that's just a mistake on my side. |
|
@vanroekel, I don't appear to be able to compute the full offline MOC because we're missing the 2 MLE velocity fields in timeSeriesStatsMonthly. |
xylar
changed the title
xylar
force-pushed
the
update_moc_calc
branch
from
092db2c to
80b9e30
Compare
xylar
force-pushed
the
update_moc_calc
branch
from
80b9e30 to
48f5822
Compare
When computing the transport through the southern boundary, use the time-averaged layer thickness (averaged from cell centers to edges), rather than the reference z-level thickness.
|
Results now match the analysis member to the degree expected: |
|
@milenaveneziani, this is now ready to review when you have a chance. |
There was a problem hiding this comment.
@xylar: I went through the code and things look good to me!
|
Great, I'll merge as soon as E3SM-Project/E3SM#5170 is on master (perhaps tomorrow?). |
This is the correct value in the MPAS-Ocean code
To match changes made in E3SM in E3SM-Project/E3SM#5170, this merge changes the transport computation into the southern boundary of an MOC region to work from the bottom up rather than the top down.
This merge also adds the submesoscale velocity to the postprocessed MOC computation.
Finally, we also add the full AMOC to the time-series output for debugging and follow-up analysis. No plots are made of these fields.