time coordinates and file for dust deposition are incorrect for new stream functionality #404

mvertens · 2024-09-16T08:45:03Z

In order to use the CDEPS stream functionality for forcing data - the time coordinate needs to be of the form

	double time(time) ;
		time:long_name = "time" ;
		time:units = "days since 0001-01-01 00:00:00" ;
		time:calendar = "noleap" ;

(since this is a climatology - noleap should be used)

However, looking at the file /cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_tnx1v4_20171107.nc
the time coordinate is

	double time(time) ;
		time:standard_name = "time" ;
		time:units = "day as %Y%m%d.%f" ;
		time:calendar = "proleptic_gregorian" ;

and the values are all zero

$ ncdump -ff -v time /cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_tnx1v4_20171107.nc
 time = 0,   // time(1)
    0,   // time(2)
    0,   // time(3)
    0,   // time(4)
    0,   // time(5)
    0,   // time(6)
    0,   // time(7)
    0,   // time(8)
    0,   // time(9)
    0,   // time(10)
    0,   // time(11)
    0;  // time(12)
    }

Also - the format needs to be cdf5 not classic

$ ncdump -k /cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_tnx1v4_20171107.nc
classic

To change this you simply need to invoke
nccopy -k cdf5 oldfile newfile

The text was updated successfully, but these errors were encountered:

mvertens · 2024-09-16T08:49:20Z

@monsieuralok - I see that you created the following files:

-rw-rw-rw-. 1 agu002 noresm   2224868 May  6  2013 /cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_tnx2v1_20130506.nc
-rw-rw-rw-. 1 agu002 noresm  15524700 Nov  7  2017 /cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_tnx1v4_20171107.nc
-rw-r--r--. 1 agu002 noresm 185957276 Oct  4  2018 /cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_tnx0.25v4_20181004.nc
-rw-rw-r--. 1 agu002 noresm 698342880 Jul 24  2020 /cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_tnx0.125v1_20200722.nc
-rw-rw-r--. 1 agu002 noresm 697052640 Oct 12  2022 /cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_tnx0.125v4_20221005.nc

Can new files please be created with the changes requested above? Moving forwards we will only need one higher resolution data to work with.

JorgSchwinger · 2024-09-16T08:52:00Z

Dear @mvertens

let me try to find the original input file, I think this file has been interpolated between different grids a couple of times. I'll search for it now and come back to you.

mvertens · 2024-09-16T09:38:43Z

@JorgSchwinger - thank you! I'm happy to work with just the original file - that is the advantage of this new capability.

JorgSchwinger · 2024-09-16T12:25:08Z

@mvertens I have found the original input file, but now nird has been shut down, so I can't work on it (the time dimension is also not as requested, I have to find some cdo/ncl magic to adjust this).

mvertens · 2024-09-16T12:26:49Z

@JorgSchwinger - thanks for tracking this down. For testing I can simply modify one of the current datasets using a simple ncdump/ncgen combination to validate if my code at least produces reasonable results.

mvertens · 2024-09-16T18:29:49Z

@JorgSchwinger - how can I test to see if using the streams for the iron dust deposition is reasonable (I would assume that if I read in a tnx1v4 dust deposition data from the streams and compared it to the current read it should be similar). I'm not sure what to look for in the output history files from blom - or if any of this information is actually being written out.

JorgSchwinger · 2024-09-16T19:53:40Z

@mvertens please find the adjusted (to meet CDEPS requirements) original dust deposition file here

dustdep_mhw2006_T42.zip

I hope everything is correct with time axis and format, please let me know if not.

I did not adjust the units of the original file (kg/m2/s) to the strange units HAMOCC is expecting (kg/m2/month). I guess this can be adjusted through a unit conversion in the stream (use 30 days per month)?

Regarding testing the stream capability: Unfortunately, HAMOCC does not output the dust (iron) field, so there is no straightforward way to compare. I can offer to run a longer NOINYOC case with the new stream functionality to compare to a corresponding case with the old input.

Finally, I would like to move to a better dust input data set, which will be easy once the new stream-functionality is implemented, right? I will open a separate issue for this

mvertens · 2024-09-16T20:21:14Z

@JorgSchwinger - thank you!!! It should be easy to do the unit conversion once the data is read in. If you are free tomorrow - or Wednesday - can we have a quick zoom chat just to look over what I've done. I want to make sure that I don't need to call fill_global for my implementation - since I'm not allocating any halo points (as is the case in mo_read_fedep.F90).

JorgSchwinger · 2024-09-17T06:27:07Z

@mvertens I'm happy to have a chat later today. I'm in a seminar until 10 and have a lunch meeting 11:30-12:30 otherwise I'm free

mvertens · 2024-09-17T16:33:06Z

@JorgSchwinger - in looking at
RIVINFILE = '/cluster/shared/noresm/inputdata/ocn/blom/bndcon/river_nutrients_GNEWS2000_tnx1v4_20170820.nc' it looks like this has no time coordinates. Is that really what we want in the future? If so - this is not what CDEPS can handle. So we either have to introduce a time coordinate with duplicate yearly values and just cycle over them - or simply provide a routine that just remaps the data to the model grid. If we don't expect time coordinates moving forward I would vote for the latter.

jmaerz · 2024-09-17T16:44:03Z

Mmmh, I see that we don't have any scaled river input with yearly runoff currently in the boundary folder for rivers (yearly run-off of a historical and future NorESM simulation used to scale the nut. -input climatology) - while I believe that there was such thing for earlier/other NorESM versions developed by S. Gao (https://bg.copernicus.org/articles/20/93/2023/bg-20-93-2023.html). This would be the/a fall-back solution to currently envisaged interactive coupling through MOSART. Hence, I would upvote for cycling over a climatological year for now, hence introducing a time coordinate.

mvertens · 2024-09-17T16:48:39Z

Thanks @jmaerz. Would it be possible for you or @JorgSchwinger to create that dataset? That would be super helpful while I try to validate the current code I am implementing for fedust.

jmaerz · 2024-09-17T17:02:58Z

Dear @mvertens , I think for now, it would mean to put a time coordinate on the climatological data you referred to above. Let's see, what @JorgSchwinger says and then let's move forward with this - Jörg or I can generate such climatological file. When you @mvertens write duplicate values - does that mean to have values for each simulated year or is it enough to put (any) year as time coordinate (and simply re-use this year as climatology)? Sorry for the latter simple question, but I am not yet familiar with these interfaces.

For any scaled input data for 1850-future, we would need a historical and scenario simulations, which is currently likely out of the scope of what we should/want to do at the moment (while having the fallback ready from a technical perspective would be useful, I believe - giving some peace to mind). Maybe we can consider using CMIP6 riverine efflux simulations to scale the data - for technical testing purposes. I'll talk to Jörg about it.

mvertens · 2024-09-17T17:33:09Z

@jmaerz - we would need to duplicate the data in the file - so if the time coordinate had 2 values (say yearly) then there would have to be duplicate values for that data.

JorgSchwinger · 2024-09-17T20:57:30Z

@mvertens river nutrients is a constant field, yes.

CDEPS can interpolate in space AND time but not in space if there is not time-interpolation? Seems unnecessarily restrictive to me :)

Anyway, the riverine input data set (GNEWS2) isn't time resolved, so this is what we have. (The scaling with river-runoff has been done, but there are also quite strong assumptions behind this). I'm sure something better will become available in the foreseeable future, but I guess for now we need to duplicate the data.

I have looked into creating the input fields on a 0.5 x 0.5 degree grid, but I didn't get the original scripts to work yet (the GNEWS2 data comes in Excel-files...). I'm on it, but it will take a bit more time.

mvertens · 2024-09-17T21:04:35Z

@JorgSchwinger - CDEPS is designed to read time dependent forcing data with at least 2 time slices. As I mentioned before - we can write functionality in BLOM to simply regrid data without any time axis - but that would not be part of CDEPS. I'm happy to do that and it would not be hard. It could also be reused for other forcing data that I see has no time axis - like SWA. Maybe we should chat before we start duplicating data on the files.

mvertens · 2024-09-18T07:23:51Z

@JorgSchwinger @jmaerz - the more I've thought about this the more I think that the right solution now is to simply regrid the incoming data if there is not a time coordinate on the file. It will be easy to switch to CDEPS streams if new files come in with time coordinates - but I think that putting the regridding functionality in now will be the right approach and take less time then creating new datasets that have duplicate data.

JorgSchwinger · 2024-09-18T08:21:04Z

@mvertens I agree that this would be the better solution for now (if it doesn't put too much work on you).

mvertens · 2024-09-18T08:23:04Z

@mvertens please find the adjusted (to meet CDEPS requirements) original dust deposition file here

dustdep_mhw2006_T42.zip

I hope everything is correct with time axis and format, please let me know if not.

I did not adjust the units of the original file (kg/m2/s) to the strange units HAMOCC is expecting (kg/m2/month). I guess this can be adjusted through a unit conversion in the stream (use 30 days per month)?

Regarding testing the stream capability: Unfortunately, HAMOCC does not output the dust (iron) field, so there is no straightforward way to compare. I can offer to run a longer NOINYOC case with the new stream functionality to compare to a corresponding case with the old input.

Finally, I would like to move to a better dust input data set, which will be easy once the new stream-functionality is implemented, right? I will open a separate issue for this

Currently the way CDEPS is normally used we interpolate every time step. We don't simply take the month value and keep it constant for the month (which I think is what hamocc is doing now). This might not be a big difference - but I'm concerned that it's not right.

jmaerz · 2024-09-18T09:03:27Z

@mvertens and @JorgSchwinger , just to mention this: I am a bit concerned with regards to automatized regridding in this particular case for riverine input in general, since i) it needs to consider land-ocean masks conservatively and ii) as far as I am aware of, it sometimes has required to diffuse the source across a number of grid boxes to not run into numerical issues or too unrealistic biogeochemistry values due to too high input into one grid-box (and too low horizontal and/or vertical mixing in the ocean model) - the latter required/s handwork for the riverine input masks. But I am happy to be proven wrong or to learn about new methods to catch those things automatically, when regridding.

mvertens · 2024-09-18T09:08:27Z

@jmaerz @JorgSchwinger - here is the output of the stream versus original for fedep

I have added the capability to output to a new netcdf file for any forcing data we want to look at.
The left is the original and the right is the stream. I am using a new file that @JorgSchwinger created to calculate this. The units are kg/m2/month.

JorgSchwinger · 2024-09-18T09:09:19Z

@jmaerz the regridding as it has been done was not conservative. So the (integrated total) riverine input is slightly different on different grids. Given the large uncertainties that come with the input data I don't think this is a huge problem.

mvertens · 2024-09-18T09:10:51Z

@mvertens and @JorgSchwinger , just to mention this: I am a bit concerned with regards to automatized regridding in this particular case for riverine input in general, since i) it needs to consider land-ocean masks conservatively and ii) as far as I am aware of, it sometimes has required to diffuse the source across a number of grid boxes to not run into numerical issues or too unrealistic biogeochemistry values due to too high input into one grid-box (and too low horizontal and/or vertical mixing in the ocean model) - the latter required/s handwork for the riverine input masks. But I am happy to be proven wrong or to learn about new methods to catch those things automatically, when regridding.

@jmaerz - the regridding can handle conservative masked mapping - but it cannot handle the type of diffusion across grid boxes that you are referring to here. If you need to customize the riverine input - then what I am proposing to do will not work. It would be good to have consensus on this before I do this.

JorgSchwinger · 2024-09-18T09:12:00Z

@jmaerz @JorgSchwinger - here is the output of the stream versus original for fedep I have added the capability to output to a new netcdf file for any forcing data we want to look at. The left is the original and the right is the stream. I am using a new file that @JorgSchwinger created to calculate this. The units are kg/m2/month.

Is this the same month? Looks quite a bit different off the coast of Africa?

jmaerz · 2024-09-18T09:14:16Z

Same question here. - or is it a time snapshot right, and the monthly mean to the left?

JorgSchwinger · 2024-09-18T09:14:52Z

It would be good to have consensus on this before I do this.

As mentioned above the mapping of riverine inputs was done in a non-conservative fashion (bilinear interpolation) before, I think we can stick to this (at least when the riverine input comes from a data set and total mass conservation isn't the primary concern)

mvertens · 2024-09-18T09:16:05Z

@JorgSchwinger - this is the same month - but I am plotting out the first time sample only. Since we are using cyclical time interpolation - and I am starting on Jan. 1 - I think that December is being used. I'll use a differrent time interpolation and see if that fixes things.

JorgSchwinger · 2024-09-18T09:20:09Z

Currently the way CDEPS is normally used we interpolate every time step. We don't simply take the month value and keep it constant for the month (which I think is what hamocc is doing now). This might not be a big difference - but I'm concerned that it's not right.

Yes, currently HAMOCC uses constant values per month, I think it is fine to use time interpolation. We probably should add a model output for the actually applied dust input then (before we had the monthly values in the dust-input file, but with CDEPS this is no longer the case)

JorgSchwinger · 2024-09-18T09:21:03Z

@JorgSchwinger - this is the same month - but I am plotting out the first time sample only. Since we are using cyclical time interpolation - and I am starting on Jan. 1 - I think that December is being used. I'll use a differrent time interpolation and see if that fixes things.

A mid-month time slice should then give very similar results, right?

mvertens · 2024-09-18T09:22:23Z

Yes, currently HAMOCC uses constant values per month, I think it is fine to use time interpolation. We probably should add a model output for the actually applied dust input then (before we had the monthly values in the dust-input file, but with CDEPS this is no longer the case)

So the time interpolation can be one of the following: [lower,upper,nearest,linear,coszen]
I was using linear. However, by setting it to lower it should be much closer to what was being done before and it will only change values once you go past the time upper bound (i.e. the new month). I'll send out a new plot once that's done.

JorgSchwinger · 2024-09-18T09:29:19Z

So the time interpolation can be one of the following: [lower,upper,nearest,linear,coszen]
I was using linear. However, by setting it to lower it should be much closer to what was being done before and it will only change values once you go past the time upper bound (i.e. the new month). I'll send out a new plot once that's done.

There was no particular rationale behind using a constant value per month - it was just the simplest solution. From a physical/biogeochemical point of view linear time interpolation is the right thing to do. So I would leave it at 'linear' (I can implement model output for the dust (or iron) field once the CDEPS implementation is done.

mvertens · 2024-09-18T09:32:31Z

@JorgSchwinger - so moving it to 'lower' did not really effect the answer very much. I'm wondering if the source of the datasets are different in what I'm comparing.

Here is the dataset that is being used in the original:
/cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_tnx1v4_20171107.nc
// global attributes:
:CDI = "Climate Data Interface version 1.6.7 (https://code.zmaw.de/projects/cdi)" ;
:Conventions = "CF-1.4" ;
:history = "Tue Mar 17 14:35:30 2015: cdo remapbil,sample_tnx1.nc INPDUST_mhw_gx1.nc INPDUST_mhw_tnx1.nc\n",
"Tue Mar 17 14:29:34 2015: ncatted -a coordinates,DUST,o,c,plon plat INPDUST_mhw_gx1.nc\n",
"Tue Mar 17 14:29:17 2015: ncatted -a coordinates,DUST,o,c,plon plat� INPDUST_mhw_gx1.nc\n",
"Tue Mar 17 14:28:15 2015: ncks -A -v plon,plat -o INPDUST_mhw_gx1.nc /work/shared/noresm/inputdata/ocn/micom/gx1v6/20100629/grid.nc" ;
:NCO = "4.0.9" ;
:CDO = "Climate Data Operators version 1.6.7 (https://code.zmaw.de/projects/cdo)" ;

And here is the source of the new dataset you provided:
/cluster/shared/noresm/inputdata/ocn/blom/bndcon/dustdep_mhw2006_T42.nc
// global attributes:
:Conventions = "CF-1.0" ;
:source = "CAM" ;
:case = "cam3019aersomb" ;
:title = "" ;
:logname = "" ;
:host = "" ;
:Version = "$Name: $" ;
:revision_Id = "$Id: history.F90,v 1.26.2.56.4.1 2004/12/28 00:46:00 aconley Exp $" ;
:history = "Tue Jan 23 11:47:36 2007: ncatted -O -a units,dustdep,c,c,kg/m2/s SOMB.month.nc\n",
"Tue Jan 23 11:46:31 2007: ncatted -O -a units,,dustdep,c,c,kg/m2/s SOMB.month.nc\n",
"Tue Jan 23 11:45:52 2007: ncrcat -v lat,lon,time,dustdep SOMB.dep.month.nc SOMB.month.nc\n",
"Mon Mar 6 15:54:05 2006: ncap -s dustdep=DSTSFDRY-DSTSFWET SOMB.dep.month.nc temp.nc\n",
"Mon Mar 6 15:28:06 2006: ncap -s dustdep=DSTSFDRY-DSTSFWET SOMB.dep.month.nc temp.nc\n",
"Mon Mar 6 15:27:35 2006: ncrcat -v DSTSFDRY,DSTSFWET average.cam3019aersomb.month.nc SOMB.dep.month.nc\n",
"Thu Mar 17 14:07:22 2005: ncrcat average.cam3019aersomb.01.nc average.cam3019aersomb.02.nc average.cam3019aersomb.03.nc average.cam3019aersomb.04.nc average.cam3019aersomb.05.nc average.cam3019aersomb.06.nc average.cam3019aersomb.07.nc average.cam3019aersomb.08.nc average.cam3019aersomb.09.nc average.cam3019aersomb.10.nc average.cam3019aersomb.11.nc average.cam3019aersomb.12.nc average.cam3019aersomb.month.nc\n",
"Thu Mar 17 13:53:15 2005: ncra cam3019aersomb.cam2.h0.0001-01.nc cam3019aersomb.cam2.h0.0002-01.nc cam3019aersomb.cam2.h0.0003-01.nc cam3019aersomb.cam2.h0.0004-01.nc cam3019aersomb.cam2.h0.0005-01.nc cam3019aersomb.cam2.h0.0006-01.nc cam3019aersomb.cam2.h0.0007-01.nc cam3019aersomb.cam2.h0.0008-01.nc cam3019aersomb.cam2.h0.0009-01.nc cam3019aersomb.cam2.h0.0010-01.nc cam3019aersomb.cam2.h0.0011-01.nc cam3019aersomb.cam2.h0.0012-01.nc average.cam3019aersomb.01.nc" ;

I can't really compare the new streams exactly unless we modify the original tnx1v4 dataset to have the right time coordinates.

jmaerz · 2024-09-18T09:33:26Z

@JorgSchwinger , have you had issues with the riverine diffusion of nutrients previously in iHAMOCC? - I just know it it from previous work and discussions around this question. It seems, that the input is currently already much diffused, which may alleviate the issue. Just for info: I just checked DSi riverine input as an example and differences between tnx0.25 and tnx2 are indeed relatively small (despite the at first look very different input patterns): 5.1263e+09 versus 5.1330e+09 globally.

JorgSchwinger · 2024-09-19T07:49:28Z

I'm wondering if the source of the datasets are different in what I'm comparing.

@mvertens as mentioned before, the tn1x4 dataset has been interpolated several times. It has not been created from the original data set, which is the T42 version you have. In that file you can see in the history that it was created from the original model output that created the dust deposition.

Although the differences in the two plots seem to me larger than just caused by interpolating several times back and forth.

Regarding the river-nutrients: I have looked into creating this on a regular grid as a basis for interpolation by CDEPS. The problem with this is that I would need to create a mapping where the data is distributed around the river mouth (i.e. what the runoff-maps are doing). I wonder if this is worth the effort, or should we just go with the existing file for the tnx0.25 grid, which should be high enough resolution to remap to any other grid by CDEPS?

mvertens · 2024-09-19T07:55:36Z

@JorgSchwinger

in terms of the dust - the only other way to verify that CDEPS is working is to put a new time coordinate in the existing dataset and read that in with CDEPS and then compare it. At that point the results should absolutely be very close. Should we do that?
In terms of the river nutrients - I think we should just use the tnx02.5 dataset. I've now written the code to do the interpolation without using CDEPS and would be happy to test this using the tnx02.5 data.

JorgSchwinger · 2024-09-19T08:26:30Z

Yes, why not creating a new version of the file with correct time-coordinates. This can be easily used for testing by putting the filename of the new file in the user-namelist. Should I do this?
Another question regarding the nutrients, since I have also looked a bit more into the (pre CDEPS) regridding of the river nutrients: My initial statement that it is just bi-linear interpolation was wrong. The mapping from the runoff-grid to the model grid does make all possible efforts to conserve mass - it's not perfect, because of diffusing the river inputs around the river mouth, but it is close (as @jmaerz confirmed for the 2 and 1/4 degree grids). So, as an example, if we now re-grid from 1/4 to 2 degree using CDEPS, there will be many grid cells in the 1/4-degree grid that are entirely land in the 2-degree grid. What will happen with the input in these grid cells?

jmaerz · 2024-09-19T08:29:08Z

More a general question @JorgSchwinger , wrt the riverine input: how is BLOM handling the freshwater fluxes in that respect - does BLOM somewhat offer a diffusive mask to not run into numerical issues with freshwater fluxes or are freshwater fluxes really in one grid cell? - ok, I guess, I should also trace this down to better understand.

mvertens · 2024-09-19T09:07:06Z

@JorgSchwinger

Yes - if you could generate a new version of the file that would be really helpful. I can then use it to test.
That is a good question. We could explore using nearest neighbor methods with masking.
"neareststod" / "nearestdtos"
See https://earthsystemmodeling.org/docs/nightly/develop/ESMF_refdoc/node5.html#SECTION05012300000000000000
I think we want nearestdtos.
Maybe a chat would help?

JorgSchwinger · 2024-09-19T15:08:50Z

@mvertens regarding the nutrients:

how is/will the mapping be done for the freshwater inputs in BLOM? For the nutrients, we would like to stay consistent with the freshwater input.

mvertens · 2024-09-19T15:17:52Z

@JorgSchwinger - are you referring to the liquid and ice runoff coming from MOSART?

jmaerz · 2024-09-19T15:24:54Z

@mvertens , yes, that's @JorgSchwinger and I briefly discussed today - how it is done with the freshwater input from MOSART to BLOM - and whether there are changes anticipated, etc.

mvertens · 2024-09-19T15:24:57Z

The freshwater runoff->blom mapping is done with conservative mapping followed by nearest neighbor smoothing. It is a custom mapping file that is read in and is the only mapping that is not done with on-line regridding. If you need custom mapping from the file - then the code I'm writing for the mapping is not needed and you will have to generate new nutrient files for every resolution.

JorgSchwinger · 2024-09-19T15:25:37Z

yes, or the runoff coming from DLND (not sure it still comes from DLND, I mean the data model that handles runoff)

mvertens · 2024-09-19T15:25:57Z

@JorgSchwinger @jmaerz - before I do any more work on this, it would be helpful to have a chat. I would find that very helpful.

mvertens · 2024-09-19T15:27:02Z

@JorgSchwinger - there is no runoff coming from DLND. All runoff to the ocean comes from MOSART. And the mosart->blom mapping is the only custom mapping that is currently used in noresm2.5.

mvertens · 2024-09-19T15:30:55Z

To see the rof->ocn mapping code look at noresm2_5_alpha05
$SRCROOT/cime/tools/mapping/gen_mapping_files/runoff_to_ocn

jmaerz · 2024-09-19T15:31:33Z

I should be more available again from tmw afternoon onward. Next week, I have a few meetings and other appointments, but would be generally open - but I also would suggest to have a chat on this topic, since it surfaces a lot of technical intricacies. In addition, maybe it would be good to have a sneak preview on how you currently implement the fluxes e.g. for iron or N-deposition (whichever fluxes you touched already in more detail) - to be able to follow this a bit in code space.

mvertens · 2024-09-19T15:34:34Z

@jmaerz @JorgSchwinger - tomorrow afternoon works for me. I can show you both the dust code as well as the new code I've implemented for mapping for river nutrients. It would be great to walk you through that. Thinking about this some more - the new blom river nutrient code can also be used to read in a rof->blom mapping file and use that to do the mapping exactly like is done for mosart. @JorgSchwinger - let me know if you can also meet tomorrow afternoon.

JorgSchwinger · 2024-09-19T15:36:36Z

I'm free tomorrow for a chat.

What I didn't understand before was that the freshwater is still done with a custom mapping file. I strongly assume that this is mapping from a 0.5 x 0.5 degree "runoff-grid" to the respective model grid (e.g. map_r05_to_tnx1v4_e1000r300_170609)? If this is the case I would tend to suggest to use the same mapping for the river nutrients, too. If a mapping file is available it won't be difficult to create the river nutrient input for the tnx05 grid.

jmaerz · 2024-09-19T15:42:50Z

@JorgSchwinger , let us know what suits you best in terms of time. I should be available from 1PM onward (while there is a minimal risk that this changes, which shouldn't hold us back to try meeting).

mvertens · 2024-09-19T15:43:47Z

Yes - mapping files are available - see $SRCROOT/ccs_config/maps_nuopc.xml:

<gridmap rof_grid="r05" ocn_grid="tnx1v4" >
  <map name="ROF2OCN_LIQ_RMAPNAME">cpl/cpl6/map_r05_to_tnx1v4_e1000r300_170609.nc</map>
  <map name="ROF2OCN_ICE_RMAPNAME">cpl/cpl6/map_r05_to_tnx1v4_e1000r300_170609.nc</map>
</gridmap>
<gridmap rof_grid="r05" ocn_grid="tnx0.5v1" >
  <map name="ROF2OCN_LIQ_RMAPNAME">cpl/cpl6/map_r05_to_tnx0.5v1_e300r100_20240702.nc</map>
  <map name="ROF2OCN_ICE_RMAPNAME">cpl/cpl6/map_r05_to_tnx0.5v1_e300r100_20240702.nc</map>
</gridmap>

Looks like we don't have one for tnx2v1 or tnx0.125v4 which we really should create.

JorgSchwinger · 2024-09-19T15:46:43Z

@mvertens 1PM tomorrow is fine for me. Also later than this works for me (not after 4pm though)

JorgSchwinger · 2024-09-19T16:23:14Z

Thinking about this some more - the new blom river nutrient code can also be used to read in a rof->blom mapping file and use that to do the mapping exactly like is done for mosart.

There we go! I'll provide the river nutrients on the 0.5 x 0.5 "runoff grid" that is used for freshwater and the mapping can be done exactly the same as for the freshwater. No additional mapping grids needed since this is done for BLOM anyway.

Would that be an option or am I missing something?

mvertens · 2024-09-19T16:39:05Z

You have it right. I think we have a solution! I'll walk you both through the code tomorrow.

mvertens added the enhancement New feature or request label Sep 16, 2024

mvertens added this to the NorESM2.5 - BLOM/iHAMOCC milestone Sep 16, 2024

mvertens added this to NorESM Development Sep 16, 2024

github-project-automation bot moved this to Todo in NorESM Development Sep 16, 2024

time coordinates and file for dust deposition are incorrect for new stream functionality #404

time coordinates and file for dust deposition are incorrect for new stream functionality #404

Comments

mvertens commented Sep 16, 2024

mvertens commented Sep 16, 2024

JorgSchwinger commented Sep 16, 2024

mvertens commented Sep 16, 2024

JorgSchwinger commented Sep 16, 2024

mvertens commented Sep 16, 2024

mvertens commented Sep 16, 2024

JorgSchwinger commented Sep 16, 2024

mvertens commented Sep 16, 2024

JorgSchwinger commented Sep 17, 2024

mvertens commented Sep 17, 2024

jmaerz commented Sep 17, 2024 • edited Loading

mvertens commented Sep 17, 2024

jmaerz commented Sep 17, 2024

mvertens commented Sep 17, 2024

JorgSchwinger commented Sep 17, 2024

mvertens commented Sep 17, 2024

mvertens commented Sep 18, 2024

JorgSchwinger commented Sep 18, 2024

mvertens commented Sep 18, 2024

jmaerz commented Sep 18, 2024

mvertens commented Sep 18, 2024

JorgSchwinger commented Sep 18, 2024

mvertens commented Sep 18, 2024

JorgSchwinger commented Sep 18, 2024

jmaerz commented Sep 18, 2024

JorgSchwinger commented Sep 18, 2024

mvertens commented Sep 18, 2024

JorgSchwinger commented Sep 18, 2024

JorgSchwinger commented Sep 18, 2024

mvertens commented Sep 18, 2024 • edited Loading

JorgSchwinger commented Sep 18, 2024

mvertens commented Sep 18, 2024

jmaerz commented Sep 18, 2024 • edited Loading

JorgSchwinger commented Sep 19, 2024

mvertens commented Sep 19, 2024

JorgSchwinger commented Sep 19, 2024

jmaerz commented Sep 19, 2024

mvertens commented Sep 19, 2024

JorgSchwinger commented Sep 19, 2024

mvertens commented Sep 19, 2024

jmaerz commented Sep 19, 2024

mvertens commented Sep 19, 2024

JorgSchwinger commented Sep 19, 2024

mvertens commented Sep 19, 2024

mvertens commented Sep 19, 2024

mvertens commented Sep 19, 2024

jmaerz commented Sep 19, 2024

mvertens commented Sep 19, 2024

JorgSchwinger commented Sep 19, 2024

jmaerz commented Sep 19, 2024

mvertens commented Sep 19, 2024

JorgSchwinger commented Sep 19, 2024

JorgSchwinger commented Sep 19, 2024

mvertens commented Sep 19, 2024

jmaerz commented Sep 17, 2024 •

edited

Loading

mvertens commented Sep 18, 2024 •

edited

Loading

jmaerz commented Sep 18, 2024 •

edited

Loading