Comments (19)
I tried to experiment with adding hyam and hybm to the files after averaging but I was unable to find the script that decides if the averaging should be done or not. In an older version of the diagnostics there used to be a test checking if the files were already there or not. I also notice that the files are touched twice. First only creating grid information but lacking hyam and hybm and then just adding the main variables.
from cam.
@oyvindseland, @MichaelSchulzMETNO, @YanchunHe, @mvertens
I have spent some time investigating why the SE history files do not have P0
, hyam
, or hybm
.
Conclusion: I now believe they should not be on the history file and should not be used for diagnostic processing of SE history output.
Background: For many dynamical cores, including FV, the vertical coordinate is constructed from the hybrid coefficients (hyam
and hybm
) with P0
serving as the reference pressure. However, the spectral-element dycore (SE) uses a dry dynamical coordinate. The pressure-coordinate terms (hyam
, hybm
, and P0
) do not describe this vertical coordinate.
The old diagnostic package does not work without these hybrid-coordinate terms because they are fed to the NCL function, pres_hybrid_ccm
which uses them to do vertical interpolation. This interpolation will not be correct for SE output and will give incorrect results. This may be the source of the negative values seen in some NorESM2.5 prototype diagnostic code.
Note: When the old diagnostic package was first adapted to handle SE output, the SE dycore at that time had not yet switched to the dry vertical coordinate. See this JAMES article for more information on that switch.
Working with the old diagnostic package is quite difficult because the incorrect interpolation functionality is used in several files. I think we should re-open the discussion on bringing in a new package and working to make it meet our needs.
from cam.
Thanks for the explanation...My immediate reaction - but there must be a way to convert coordinates. How shall other people in the CMIP world work with this coordinate system?
from cam.
Thanks for the explanation...My immediate reaction - but there must be a way to convert coordinates. How shall other people in the CMIP world work with this coordinate system?
Yes. I think the issue is that the current diagnostic scripts do not have any organized place where this could be done. This is because the underlying NCL library has a function that does the interpolation for the FV (and earlier) dycore's vertical coordinate. To do the appropriate interpolation within the current scripts would require refactoring that code to call a new routine that would know about which vertical coordinate was being used.
There are some alternatives, we need to discuss which we want to pursue.
from cam.
I was more thinking of some preprocessing of files, before they enter the diagnostics scripts.
How wrong do the diagnostics get if the dry coordinate is assumed to be the wet coordinate? And is the bias possibly always nearly the same for different model versions?
from cam.
I see there is another NCL subroutine, pres_hybrid_ccm_se, for the spectral element coordinate. It also requires hyai
and hybi
. Is this relevant?
Adding another separate script to determine the grid/coordinate type should be straightforward (and save the grid type as a global environment variable so that other scripts can use).
from cam.
I see there is another NCL subroutine, pres_hybrid_ccm_se, for the spectral element coordinate. It also requires
hyai
andhybi
. Is this relevant?
That function dates to 2014, several years before the new SE-dycore vertical coordinate was created. Looking at the code (in contributed.ncl), it is just a wrapper for pres_hybrid_ccm
after reading the data using ncol
instead of lon
/lat
. Thus, it has the same flaw as pres_hybrid_ccm.
from cam.
That function dates to 2014, several years before the new SE-dycore vertical coordinate was created. Looking at the code (in contributed.ncl), it is just a wrapper for
pres_hybrid_ccm
after reading the data usingncol
instead oflon
/lat
. Thus, it has the same flaw as pres_hybrid_ccm.
I see, thanks for the explanation!
from cam.
from cam.
When I test the old diagnostics script with the added p0 and gw I get a limited amount of output, mostly 2D. For some reason the Taylor diagram works despite using U300. A possible explanation may be that this script use the wind at the grid edges instead of grid center. If so the (FV) vertical definitions are retained.
Example on nird: datalake/NS2345K/oyvinds/NorESM2.5diag/diag (tar file) (same as above)
I have also used a different ncl tool for the aerosol diagnostics, and model vs model intercomparison.
NorESM/components/cam/tools/diagnostics/ncl/ModIvsModII
This works with the adjustments defined above but as Steve wrote the vertical plots are are not correctly interpolated. I still think they can be used for a first glance. The 2D plots should be fine at any rate.
/datalake/NS2345K/oyvinds/NorESM2.5diag/aerosolandclouds
Main file ModIvsModII.htm
This specific set compares NF2000oslo_alpha_ne30pg3_ne30pg3_mtn14_20240430 year 1-5 with
NF1850norbc_aer2014_f19_f19_rel206_20231103/yr1-30/ so 2014 aerosols and release 2.0.6 NorESM2-LM
from cam.
I was more thinking of some preprocessing of files, before they enter the diagnostics scripts.
The issue is that the data in the history files is defined on the model pressure levels, that is, the pressure field which is also on the history file (PMID
). These levels are not the same as the dycore vertical grid. Currently, the diagnostics ignores the pressure field and assumes the simple Lagrangian hybrid vertical coordinate. I do not know how to recompute all the history fields to be on that grid -- in the model, the dycore does that.
How wrong do the diagnostics get if the dry coordinate is assumed to be the wet coordinate? And is the bias possibly always nearly the same for different model versions?
I do not have any idea how I would estimate that. I am also not sure what "different model versions" is referring to.
from cam.
But pmid varies on a model level. So there has to be some equation if you want to find the values at a certain pressure? If it is not the standard hybrid coordinate equation what is it?
from cam.
But pmid varies on a model level. So there has to be some equation if you want to find the values at a certain pressure? If it is not the standard hybrid coordinate equation what is it?
It is not a single equation. The model uses a few different algorithms to interpolate a field to a non-model pressure level:
- Linear interpolation: This is the most common approach -- simply do a linear interpolation (in pressure) of the field between the field values above and below the desired output level. This is used in the radiation code as well as most of cam_diagnostics.F90.
- Log interpolation: This is a linear interpolation of the field using the log of the pressure above and below the desired output level. This approach is used for the geopotential diagnostic fields in cam_diagnostics.F90.
- Extrapolation below lowest model level: CAM uses a couple of ECMWF algorithms to extrapolate below the lowest model level (different formulations are used for extrapolation of geopotential and temperature fields).
- Above model top: CAM does not extrapolate above the model top, it merely returns the field value for the topmost model layer.
from cam.
Thank you. For me the most important is to be able to compare CAM6 and CAM7 (NorESM2 and NorESM2.5) on the same vertical grid. If it is pressure, terrain following coordinates or height is less important.
from cam.
One question about the vertical coordinate. I presume that the internal calculation of column burdens in CAM, e.g. total water in the column is calculated on the native SE vertical grid, and not from FV? Radiation and precipitation inside the model is calculated from a loop over the tendencies in the vertical so TOM or surface does not need height information directly, so these parameters will not be impacted.
from cam.
I'm not sure I understand the question. Are you talking about diagnostics such as TGCLDCWP
? Those are just sums of the values at all vertical levels. Each level represents the amount in a "pressure level" where the value in the PMID
variable is the pressure in the middle of that level. Nothing in the physics is computed on the SE native grid.
from cam.
Yes TGCLDLWP is one example. To get a vertically integrated value you also need the pressure (or height) at the level boundaries not only mid point?
from cam.
Yes TGCLDLWP is one example. To get a vertically integrated value you also need the pressure (or height) at the level boundaries not only mid point?
No, just add the amounts, e.g. (from cloud_diagnostics.F90):
do k=1,pver
tgicewp(:ncol) = tgicewp(:ncol) + gicewp(:ncol,k)
tgliqwp(:ncol) = tgliqwp(:ncol) + gliqwp(:ncol,k)
end do
Perhaps the confusion is how to compute the amounts to be summed.:
amount(i,k) = mixing_ratio(i,k) * state%pdel(i,k) / g
where state%pdel
is the 'thickness' of the level in Pa and g
is the gravitational acceleration. This gives the amount in kg m-2
.
from cam.
OK. So state%pdel is a variable.
Then it works fine
from cam.
Related Issues (20)
- Update externals for svn workaround HOT 1
- Add new 10m wind fields to be sent from cam to mediator and then to ww3dev HOT 1
- Update of noresm physics for oslo-aero use cases for 1850, 2000 and hist HOT 1
- Add compsets for TropMAM4
- Create SpAero compset HOT 1
- Aerosol loss is larger than aerosol source terms HOT 13
- Addition of new sum diagnostics for aerosols HOT 1
- Lots of compsets can not be run with the alias HOT 2
- P0 always needs to be on history file HOT 3
- Increase convective scavenging for accumulation and coarse mode sea-salt and potentially sulphate from aqueous phase chemistry HOT 2
- Add parameteriation of secondary ice HOT 2
- Alternative formulation of cloud droplet activation
- Change yield of production of secondary organic aerosols from isoprene
- Check the if the cloud water / cloud ice tuning used in KeyClim simulations is included from in the NorESM2.3 development version
- Add namelist options for the cloud water / cloud ice tuning included from the KeyClim simulations HOT 2
- Add alternative formulation of scavenging in convective clouds. HOT 1
- Removal of tracer variable so4_ac
- NorESM2.3 : Tag/branch for OSLO_AERO in Externals_CAM.cfg HOT 7
- cam_chempp issue with usr_mech_infile when path to compiler is too long HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cam.