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

fco2nat variable (IFS grid) requires fgco2 (NEMO grid) #613

Open
etiennesky opened this issue Mar 27, 2020 · 22 comments
Open

fco2nat variable (IFS grid) requires fgco2 (NEMO grid) #613

etiennesky opened this issue Mar 27, 2020 · 22 comments

Comments

@etiennesky
Copy link
Contributor

The variable fco2nat is defined as "This is what the atmosphere sees (on its own grid). This field should be equivalent to the combined natural fluxes of carbon that account for natural exchanges between the atmosphere and land (nep) or ocean (fgco2) reservoirs."

Right now, fco2nat is output by LPJG in the IFS grid, and we have Omon:fgco2 which are the fluxes from PISCES in the NEMO grid.

fco2nat needs to be computed from fco2nat from LPJG and fgco2 from NEMO.

Is it possible to horizontally interpolate data from the NEMO grid to the IFS grid, and to add it to an existing variable?

@goord
Copy link
Collaborator

goord commented Apr 2, 2020

Yes this should be possible, but it will require some work because right now ifs2cmor assumes all input data is in spectral and gridpoint files in the same leg directory etc.

Could you explain where the variables are supposed to be found and, maybe you have an example run output we can test with?

@etiennesky
Copy link
Contributor Author

Hi @goord

we have 2 variables which are already cmorized

  1. fco2nat is output by LPJG and cmorized by lpjg2cmor.py in the Amon table with the IFS grid
./output/lpjg/001/fco2nat_monthly.out.gz
./cmor_outputs/cmor_1/CMIP/EC-Earth-Consortium/EC-Earth3-CC/piControl/r1i1p1f1/Amon/fco2nat/gr/v20200326/fco2nat_Amon_EC-Earth3-CC_piControl_r1i1p1f1_gr_185001-185012.nc
  1. fgco2 is output by NEMO (*pisces_grid_T_2D.nc file) and cmorized in the Omon table
./nemo/001/a2qd_1m_18500101_18501231_pisces_grid_T_2D.nc
./cmor_outputs/cmor_1/CMIP/EC-Earth-Consortium/EC-Earth3-CC/piControl/r1i1p1f1/Omon/fgco2/gn/v20200326/fgco2_Omon_EC-Earth3-CC_piControl_r1i1p1f1_gn_185001-185012.nc
  1. final result of fco2nat in Amon should be the sum of fco2nat (cmorized by LPJG) and fgco2 (cmorized by NEMO, regridded to IFS grid).

I would assume it might be easier to do this as a post-processing job, once the nemo and lpjg cmorization have been done.

You can find the raw and cmorized output here

ftp://bscesftp.bsc.es/etourign/ec-earth/cmor_issue_613/

@etiennesky
Copy link
Contributor Author

on second thought, it might be better to change lpjg2cmor.py to add fgco2 from NEMO to the result of fco2nat, instead of adding a post-processing step.

Is there a way that ece2cmor3 knows if the experiment was run with nemo ? Because if lpjg2cmor.py runs runs before nemo2cmor.py has run it should fail, unless there is no nemo output in that experiment.

@etiennesky
Copy link
Contributor Author

Hi @goord I am looking into a solution for this, which involves modifying the function create_lpjg_netcdf to add the values from a remapped Omon/fgco2 file. Could you point me how to find the appropriate path to the cmorized file Omon/fgco2 file?

@goord
Copy link
Collaborator

goord commented Apr 9, 2020

Hi @etiennesky you should search recursively in the output directory no? That directory you get via

cmor.get_cur_dataset_attribute("outpath")

@etiennesky
Copy link
Contributor Author

thanks @goord , that will give the root of the output -

in order to get the complete path (e.g. $outpath/CMIP/EC-Earth-Consortium/EC-Earth3-CC/piControl/r3i1p1f1/Omon/fgco2/gn/v20200323/) I need to reconstruct it from the other attributes as well, any hints on getting that?

@nierad
Copy link
Collaborator

nierad commented Apr 9, 2020

Wouldn't it actually be useful if it would also be written out by IFS?

@etiennesky
Copy link
Contributor Author

it is written out by LPJG, IFS/TM5 do not know the difference between the natural and anthropogenic unfortunately, unless we make the distinction

@nierad
Copy link
Collaborator

nierad commented Apr 14, 2020

That was my thinking. Is it costly to add extra fields to be exchanged via OASIS such that TM5/IFS have all the info needed to appropriately write it out?

@etiennesky
Copy link
Contributor Author

I am stuck in the remapping process, all cdo conservative remapping operators fail when generating the remap fields. Will try to generate the remap fields offline using oasis.

@goord
Copy link
Collaborator

goord commented Apr 22, 2020

Etienne is ifs going to output it online on the reduced grid, so lpjg sends it to ifs and ifs adds it to pextra?

@etiennesky
Copy link
Contributor Author

IFS does't have that flux... TM5 does, and then it sends daily co2 mixing ratio (not fluxes) to IFS, @nierad wrote that by mistake I think...

and we want this in the concentration-based runs where there is no co2 exchange between any components.

@etiennesky
Copy link
Contributor Author

Trying with Thomas Arsouze to generate the remap file with oasis, that is also not working now, seems that cdo does not recognize the remap file we generate. They have to have the same source grid AND mask.

@goord
Copy link
Collaborator

goord commented Apr 22, 2020

So one can discuss whether those fluxes are 'what the atmosphere sees', since tm5 uses them to prescribe concentrations for IFS? Could we get away with outputting them on the tm5 grid?

@etiennesky
Copy link
Contributor Author

implemented and will soon submit a MR for this, the output is now on the ifs grid and the nemo output is remapped wth cdo then added to the lpjg output.

@etiennesky
Copy link
Contributor Author

code is here: etiennesky@e58901b

etiennesky@08163fb

@etiennesky etiennesky mentioned this issue Jun 16, 2020
@etiennesky
Copy link
Contributor Author

see the MR

@etiennesky
Copy link
Contributor Author

I have uploaded test data in

ftp://bscesftp.bsc.es/etourign/ec-earth/cmor_issue_613/

@etiennesky
Copy link
Contributor Author

MR updated and ready for review

@treerink treerink mentioned this issue Jul 17, 2020
@treerink
Copy link
Collaborator

The fco2nat branch is merged into the master branch.

@etiennesky etiennesky reopened this Mar 8, 2021
@etiennesky
Copy link
Contributor Author

Hi @treerink @goord @pabretonniere @aeramos

Note I added a comment here about this issue #635 (review)

I am having a minor issue with this feature, when nemo/pisces is not activated (this happens in AMIP runs or offline land surface runs) the code fails because the nemo output variable fgco2 is not found. I added this as a safeguard to be sure that we always get the correct output, I think due to someone's suggestions last year.

However, I would like to be able to override this when I am certain that no nemo output exists.

I there any way this can be detected inside ece2cmor3 or passing a flag to lpjg2cmor.py ?

@goord
Copy link
Collaborator

goord commented Mar 8, 2021

Hi @etiennesky this should be implemented with an extra flag to lpjg2cmor, because once the separate components are running, they have no way of knowing whether the run had nemo output...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants