Vestland Climate Grids enhencement for NorESM-LSP (may be a new branch of the platform?)

[huitang-earth]

As far as I know, there have been several modelling work planned for Vestland Climate Grids, including my moss model development, @ecaas soil decomposition model, @evalieungh transplant experiments etc.

These work require a better input data and setup for these sites, which are not available in the current version of the platform.

I have spent some efforts together with @kjetilaas, @srg101, @ingealthuizen to improve some of the input data for our moss work, which include:

• Climate forcing from COSMO-REA 6km resolution, 1995-2019. This has been tested to be significantly better than the default forcing GSWP3 for the Vestland Grid. It might also work better than ERA5 owing to its high spatial resolution.
• A python script for automatically downloading climate forcing from ERA5 (about 30 km resolution) for a site and convert to a format that CTSM-FATES need. The time periods can be extended to near real time about 1-3 months time lag.
• Surface data that include observed vegetation cover fraction, plant height, soil depth (bedrock), soil organic matter and slope!
• PFT parameters file for moss.

Hope these information serve as a starting point for anyone who is interested in further enhencing the input and setup data for Vestland Climate Grid sites. I am happy to share these these efforts already through the platform. Perhaps, a new branch of the platform for Vestland climate grids enhancement would be a good idea?

Please let me know your opinions, especially those who plan to work on these sites using the platform @evalieungh and @ecaas.

[evalieungh]

Setting up a new branch sounds like a good idea, @huitang-earth, and I agree it would be nice to make individual developments available for everyone through work on a new branch. @ecaas and I have glanced at your script for making the surface data already, and wondered how much work is needed to re-run them if necessary and to store the data somewhere available for the LSP.

About the COSMO data, we should coordinate with @yelizy who is also working on making improved forcing data for at least some of the VCG sites using Toposcale-downscaled ERA 5 data. I'm not familiar with which is best, but either way it doesn't hurt to have more options.

Is is possible for anyone to download the COSMO data directly from Fram via the internet, or do we have to log in to access it?

For my own project, I only need data for the four alpine (ALP1-4) VCG sites right now. Depending on how much work it is, though, it would be great to help make a coherent set of improved forcing and surface data for all the 12 VCG sites that is integrated in the LSP.

About the moss PFT, would it require changes to the code to make it available through the GUI?

Tagging old issues #141 and #40 here as they seem relevant and might be superseded by this discussion. I think we might convert this issue to a discussion thread.

[evalieungh]

Data storage thread

Linking to this discussion about input data storage for the LSP in general, where should we put new forcing data for sites?

Options include e.g. Sigma2, Zenodo, OSF, other...?

It might also be good practice for data to be published with a DOI and proper metadata including method description, version control, and citation instructions. So I favor Zenodo or something similar, where it will also be possible to link to and add creation scripts and to provide metadata and a list of creators so the whole workflow becomes more transparent.

[evalieungh]

@ecaas @huitang-earth
Elin and I just discussed a bit where to store the new data we will make for the VCG sites. My suggestion is to add them to the LSP's default data repo here: https://github.com/NorESMhub/noresm-lsp-data.
The new data files should contain site-level COSMOREA data and a modified surface data file, and be zipped. If the zipped folders end up being too big for GitHub, we need to consider something else. But for now this seems like a simple solution that is in line with LSP developments.

Other options are OSF, Zenodo or EMERALD's sigma2 storage (where older versions of LSP input data are stored).

About OSF, it seems like a logical choice to keep VCG input data together with the VCG observaltional data. But I'm not sure if it works smoothly. I haven't tried downloading OSF data from URL outside of R, but in R it is cumbersome with smaller files (requires a package/special function) and impossible for files that are too big to render in the browser.

Zenodo I also haven't tried to download directly from, so I'm not sure how easy this is. Sigma2 requires applying for access somewhere to upload the files, which seems unneccessary and might be difficult in a few years (who will have access then?).
So unless there is something we have missed here, I think the existing GitHub repo is the simplest, most open choice.

[ecaas]

Thanks for bringing this up, @huitang-earth!

I'm interested in these data as well, especially atmospheric forcing and surface data for BOR1-4, but ideally for all 12 sites. If needed, I'm happy to help putting these data together.

I'm a bit unsure if I will use the platform or not, as it might be more efficient for me to run simulations "the regular way"... So I agree with Eva about publishing the data with a DOI and proper documentation, so they can be used and referenced by a broader community.

I'm also not familiar with the difference between the COSMO-REA vs. the Toposcale-downscaled ERA5, are there big pros/cons using one over the other? In any case I guess it will be nice to have the choice within the platform, if it is possible without to much extra work.

[ecaas]

Hi again,

@evalieungh and I discussed briefly today and think it would be very useful to at least have input data for a few of the VCG sites available, so we can start testing/designing experiments.
@huitang-earth do you already have data for some/all sites, and if so would it be possible to upload them to e.g. Zenodo?
Or, if you have scripts for creating the needed files, can you share them with us? If it is a big job to make all the needed files, maybe we can share the workload somehow?

A short meeting might be useful to get an overview over what exists and what needs to be done.

[huitang-earth]

Hi, sorry for the late update.

To address the first item I mentioned in the beginning:
Climate forcing from COSMO-REA 6km resolution, 1995-2019. This has been tested to be significantly better than the default forcing GSWP3 for the Vestland Grid.

Here are more information about it (How it is processed and how it can be used in CTSM with NUOPC coupler)
https://github.com/huitang-earth/scripts_ctsm_region/blob/main/atm_forcing/cosmo_rea_6km/README.md

[evalieungh]

Thanks for the update and link to readme.

Update from @ecaas and me meeting today: Elin found the COSMOREA data on Saga and managed to run using your readme, @huitang-earth. Next week I plan to go visit her and see if I can make the same changes to a new branch of the LSP with the new compset. Then we can upload the data and run tests.

If the tests are successful, we might consider pushing these changes into the main branch of the platform, but that would take time and require changes to the documentation etc. @lasseke FYI this might happen but will take time!

[evalieungh]

Surface data

copy+paste from comment in overlapping thread:

Hi all, I'm in the process of improving the surface data for the VCG ALP1-4 sites with data from SeedClim/FunCaB/INCLINE project observations. I'm adapting @huitang-earth's script from his Moss PFT work, with my modified workflow currently stored in my INCLINE/FATES repo. The finished versions of the data can be uploaded to the LSP as well once I'm done.
Some questions have come up already:
1. (scientific:) should we change the cover fraction of different PFTs according to observations? It might be difficult to calculate, and will require combining data at different scales (subplot, plot, different years) from different VCG data sources.
2. (technical:) In the ALP1 data, there are two surface data files, surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr2000_ALP1_c221011.nc and surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr2000_ALP1_c221026.nc. Is one superfluous? It looks like the other sites only have one surfdata file. Browsing through the two files on Panoply, I have not found any difference between them. @lasseke do you remember something about this?

[evalieungh]

should we integrate the improved input data as a new branch, or as defaults for the VCG sites in the main branch?

If the COSMOREA forcing and improved surface data give better results for the VCG sites, I think it might be best to just merge the improvements into the LSP main branch after developing and testing a separate branch. Do people agree with this?

If we aim to merge the improved data into main, the improved data should be general enough that LSP users don't have to read up on the site differences a lot. So i.e. a new moss PFT should be kept separate for now, unless we can implement it for all of the sites (including LATICE-MIP sites, potential new sites, etc.).

This might also have implications for the choices in the surface data file, like PFT cover fractions and which observational data sets we use. For example, the SeedClim and INCLINE locations in the ALP sites are slightly different and will have different slope/aspect and some other differences.

[evalieungh]

Problems setting up COSMOREA for the LSP

Hi, lately I've been trying to test COSMOREA data with a branch of the platform, but I'm running into weird problems. I have tried to follow the setup used by @huitang-earth and @ecaas (huitang-earth/scripts_ctsm_region), with some modifications necessary since the LSP organises some files a bit differently.
I'm noting down everything as well as I can in a separate repo.

Today I have tested this:

1. default 1-year gswp3 forcing case, on the cosmorea branch, where the cime_config files have been replaced by the scripts_ctsm_region versions.
2. COSMOREA test case, with input data uploaded by Elin & me, and with COSMOREA instead of GSWP3 compset and other changes to try as best I can to make it work (see these notes).

In the GUI, it looks like both cases finish successfully. The default (1.) case seems to finish successfully and produces normal output files and logs. So I think the cime_config/ files are not the problem, at least. The cosmorea test case does not start properly, and produces no output and almost no logs. The only log file with any content is resources/cases/caseID/archive/logs/cesm.log.230321-160022:

Abort with message No such file or directory in file /ctsm-api/resources/model/libraries/parallelio/src/clib/pioc_support.c at line 2830
Obtained 10 stack frames.
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x8503c4) [0x5594450fe3c4]
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x850474) [0x5594450fe474]
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x85058a) [0x5594450fe58a]
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x853fcf) [0x559445101fcf]
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x84f6d4) [0x5594450fd6d4]
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x81ed46) [0x5594450ccd46]
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x703139) [0x559444fb1139]
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x70dad2) [0x559444fbbad2]
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x6fca7c) [0x559444faaa7c]
/ctsm-api/resources/cases/d3a874304132542cbdeafc4bc7bac2c0_cosmorea-test4/bld/cesm.exe(+0x113d58) [0x5594449c1d58]
application called MPI_Abort(MPI_COMM_WORLD, -1) - process 0

There is also something wrong indicated by caseID/run/datm.streams.xml which has several lines like this:

<file>UNSET//clm1pt__2000-01.nc</file>
<file>UNSET//clm1pt__2000-02.nc</file>

@yelizy already looked at this a bit today, and tomorrow I will go to Blindern to do more testing. @ecaas will you also be there tomorrow? Can we compare case folders to see what is wrong? @huitang-earth do you have an idea what might be the problem?

[ecaas]

Hi!
Yes, I'm around tomorrow, so we can compare stuff then :)
My initial thought seeing

<file>UNSET//clm1pt__2000-01.nc</file>
<file>UNSET//clm1pt__2000-02.nc</file>

is that it should be <file>path/to/datm/files/ALP1/clm1pt_ALP1_2000-01.nc</file> .
In my setup I set the path with
./xmlchange DIN_LOC_ROOT_CLMFORC=/cluster/projects/nn2806k/COSMOREA_VCG
and the site by using my hack and
./xmlchange VCGSITE=ALP1
As I understand it, it is not possible to set this in the same way in the platform, but maybe someone knows how to convert this to the platform organisation of files?

[evalieungh]

Thanks, @ecaas. I had missed that DIN_LOC_ROOT_CLMFORC also needed to be changed. Yesterday @yelizy and I made a lot of progress and managed to get the platform running with our COSMOREA data, but there were some problems. The main problem is that we could not invoke the xmlchange tool, for some reason. I'm not sure if this is a general problem or just something to do with my specific setup/machine. We were able to hardcode around it, and I think a solution is to add site-specific xmlchanges to the input data files.

For some reason, Kaveh changed the location of the user_mods directory so it is included with the input data instead of appearing in the case directory. So, to implement COSMO forcing we can enter the necessary xmlchanges directly into the user_mods/shell_commands file, i.e. set VCGSITE and DIN_LOC_ROOT_CLMFORC there.

[ecaas]

Great that you guys got it to work, good job!

For some reason, Kaveh changed the location of the user_mods directory so it is included with the input data instead of appearing in the case directory. So, to implement COSMO forcing we can enter the necessary xmlchanges directly into the user_mods/shell_commands file, i.e. set VCGSITE and DIN_LOC_ROOT_CLMFORC there.

I guess that is because he is following the ./subset data script like here. using the --create-user-mods flag in step 5 creates a shell_commands file in that directory.

[evalieungh]

Aha, then I misunderstood. I thought the user_mods were supposed to be in the case directory by default.

So now we know how to implement COSMOREA forcing in the LSP. I don't think I will prioritise making a PR, but maybe I will have time in a few months.