How to use my own forcing data to drive CLM single site simulation.

[oleson]

I'm not aware of any such scripts unfortunately. I'm personally at a loss as to how to resolve the error you are getting since I've not run into it before, and I'm not familiar with Python.

 

[jinmuluo]

I'm not aware of any such scripts unfortunately. I'm personally at a loss as to how to resolve the error you are getting since I've not run into it before, and I'm not familiar with Python.

Thank you so much for your patience and help! You've really helped me a lot! @oleson @slevis

 

[jinmuluo]

I'm not aware of any such scripts unfortunately. I'm personally at a loss as to how to resolve the error you are getting since I've not run into it before, and I'm not familiar with Python.

Hi Oleson and Sam, @oleson @slevis

I've tried to make several modifications to my case's user_nl_datm_streams, and now the "corrupted unsorted chunks" error is solved (maybe not). But another error called "error (76): Abort trap signal" appeared, I searched for this error on the cesm forum and found many people have the same question but no solution is available yet. Do you have any idea about this error?
Otherwise, I guess the problem might not be from my NetCDF files, so I'm wondering do you know any study material to learn about how to set up a new climate forcings case for CTSM SP simulation?

Best,

Jinmu

 

[oleson]

I see this in your datm.streams.xml:

<var>QBOT Sa_shum</var>

while your atmospheric forcing file has RH. You can use RH, but you need to tell the datm about it, so:

<var>RH Sa_rh</var>

and I don't see FLDS in your forcing file, which is fine, it will be calculated, but you need to tell datm not to expect it, .e.g., remove this line:

<var>FLDS Faxa_lwdn</var>

 

[jinmuluo]

I see this in your datm.streams.xml:

<var>QBOT Sa_shum</var>

while your atmospheric forcing file has RH. You can use RH, but you need to tell the datm about it, so:

<var>RH Sa_rh</var>

and I don't see FLDS in your forcing file, which is fine, it will be calculated, but you need to tell datm not to expect it, .e.g., remove this line:

<var>FLDS Faxa_lwdn</var>

Hi Oleson,

Thank you for your patience and help!
I don't know why CTSM keeps correcting my modification on the datm.streams.xml after I recompile the case, so I chose to write down those changes in my user_nl_datm_streams by typing "CLMGSWP3v1.TPQW:datavars = TBOT Sa_tbot, RH Sa_rh, WIND Sa_wind, PSRF Sa_pbot". Then I ran it again, and a new error emerged.

cesm.log
--------------------------------
forrtl: severe (408): fort: (2): Subscript #1 of the array MINPLANTJDAY has value 17 which is greater than the upper bound of 16

 

[oleson]

It looks like you have crops on but you are using a 16pft surface dataset. Crops require a 78pft dataset.

 

[jinmuluo]

It looks like you have crops on but you are using a 16pft surface dataset. Crops require a 78pft dataset.

What can I do to create a 78 pft dataset when I subset the dataset?

 

[jinmuluo]

It looks like you have crops on but you are using a 16pft surface dataset. Crops require a 78pft dataset.

This "surfdata_0.9x1.25_hist_16pfts_Irrig_CMIP6_simyr2000_isu_point_c230627.nc" was copied from a successful sp case but driven with GSWP3 forcing, so I thought it would work. If that's the problem, what can I do to create a 78 pft surface dataset when I subset the meteorological dataset?

Thank you!

 

[oleson]

Your previous case was created from a SP run so it uses a 16pft dataset. Your new case (MESCOM?) used a BGC-CROP compset when it was created (I2000Clm51BgcCrop) so it requires a 78pft dataset. It doesn't have anything to do with the meterological dataset. You'll need to setup a BgcCrop compset and then subset the 78pft dataset that is provided. Or, if you are using the subset_data tool, then add --crop to your command. See ./subset_data --help

 

[jinmuluo]

Your previous case was created from a SP run so it uses a 16pft dataset. Your new case (MESCOM?) used a BGC-CROP compset when it was created (I2000Clm51BgcCrop) so it requires a 78pft dataset. It doesn't have anything to do with the meterological dataset. You'll need to setup a BgcCrop compset and then subset the 78pft dataset that is provided. Or, if you are using the subset_data tool, then add --crop to your command. See ./subset_data --help

I'm sorry to say that, it meets a new error again ..................

cesm.log
-------------------------------------------
forrtl: error (65): floating invalid


I saw the CLM begin to run from the lnd.log, but it didn't tell me which variable has the digital problem.
-------------------------------------------
Successfully initialized the land model

begin initial run at:

nstep= 0 year= 2014 month= 1 day=

1 seconds= 0

 

[oleson]

I see a traceback in your cesm log file:

Image PC Routine Line Source
cesm.exe 000000000485661B Unknown Unknown Unknown
libpthread-2.22.s 00002B265CC98C00 Unknown Unknown Unknown
cesm.exe 0000000001A21861 fan3mod_mp_eval_d 201 Fan3Mod.F90
cesm.exe 00000000019D12E3 fan2ctsmmod_mp_fa 497 Fan2CTSMMod.F90
cesm.exe 0000000001420D24 cnndynamicsmod_mp 184 CNNDynamicsMod.F90
cesm.exe 000000000375DDB7 cndrivermod_mp_cn 302 CNDriverMod.F90
cesm.exe 000000000162025F cnvegetationfacad 965 CNVegetationFacade.F90
cesm.exe 0000000000B19A0B clm_driver_mp_clm 1007 clm_driver.F90
cesm.exe 0000000000A38192 lnd_comp_nuopc_mp 893 lnd_comp_nuopc.F90

I would look at line 201 in Fan3Mod.F90 and work back from there to see what the problem might be:

ratio_NO3_CO2 = (no3_total * 1.e3_r8 / soil_dens)/soil_co2

Perhaps a divide by zero?

 

[jinmuluo]

I see a traceback in your cesm log file:

Image PC Routine Line Source
cesm.exe 000000000485661B Unknown Unknown Unknown
libpthread-2.22.s 00002B265CC98C00 Unknown Unknown Unknown
cesm.exe 0000000001A21861 fan3mod_mp_eval_d 201 Fan3Mod.F90
cesm.exe 00000000019D12E3 fan2ctsmmod_mp_fa 497 Fan2CTSMMod.F90
cesm.exe 0000000001420D24 cnndynamicsmod_mp 184 CNNDynamicsMod.F90
cesm.exe 000000000375DDB7 cndrivermod_mp_cn 302 CNDriverMod.F90
cesm.exe 000000000162025F cnvegetationfacad 965 CNVegetationFacade.F90
cesm.exe 0000000000B19A0B clm_driver_mp_clm 1007 clm_driver.F90
cesm.exe 0000000000A38192 lnd_comp_nuopc_mp 893 lnd_comp_nuopc.F90

I would look at line 201 in Fan3Mod.F90 and work back from there to see what the problem might be:

ratio_NO3_CO2 = (no3_total * 1.e3_r8 / soil_dens)/soil_co2

Perhaps a divide by zero?

Thank you! I've learned a lot from our discussion.

The denominator "soil_dens" is more like a constant, and soil_co2 is from CLM. I've tried to run an I2000Clm51BgcCrop single point simulation case with GSWP3 forcing, of course with my personal module on, it works. The only difference between MESOCOM (using my forcing, 2014-2022) and GSWP3(2010-2014) case is the simulation time, do you think this might be the reason to lead soil_co2 has zero value in CLM?

My climate forcing dataset ranges from 2014-2022, can I use my dataset to run a simulation from 2000 to 2022 by filling the empty years with my forcings? And how to set up the cycle? I guess it would make sure CLM can start from a year with reasonable initial values. I'm not sure am right or wrong.

Thank you

 

[jinmuluo]

Thank you! I've learned a lot from our discussion.

The denominator "soil_dens" is more like a constant, and soil_co2 is from CLM. I've tried to run an I2000Clm51BgcCrop single point simulation case with GSWP3 forcing, of course with my personal module on, it works. The only difference between MESOCOM (using my forcing, 2014-2022) and GSWP3(2010-2014) case is the simulation time, do you think this might be the reason to lead soil_co2 has zero value in CLM?

My climate forcing dataset ranges from 2014-2022, can I use my dataset to run a simulation from 2000 to 2022 by filling the empty years with my forcings? And how to set up the cycle? I guess it would make sure CLM can start from a year with reasonable initial values. I'm not sure am right or wrong.

Thank you

Hi Oleson,

I guess I've figured out how to cycle the meteorological dataset, but even when I adjusted the start year to 2010 the soil_co2 (soil_co2_prod_col ) from CLM is still zero. I don't why when I ran the case with GSWP3 forcing, soil_co2_prod_col is not zero.

I tried to use if-else statement to avoid the divided by zero problems, and now my model works for a very short simulation (4 months), I should be able to continue to debug the other error.

Thank you for your help! I think this issue can be closed now.