Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu

CLM - Initialising Soil Temperatures - Segmentation Fault when using a built-in Intel LAPACK function (dgbsv) contained in BandDiagonal.F90

I have attached the relevant logs for this problem. I am running it on my machine here called Oswald (see config_compilers.xml). I have not made any source code modifications except to print out variables to the logs to try and get to the bottom of the problem.

In a nutshell, I think one of the values being passed to the function dgbsv in BandDiagonal.F90 is too large and causing the calculation to blow up and the result unable to be stored.

When I printed out rvector from line 355 of SoilTemperatureMod.F90 before it goes into BandDiagonal.F90, I get this:

2859.82508137484 NaN NaN
245.700620040328 NaN NaN
248.738494119602 NaN NaN
15849947674084.6 NaN NaN
258.175173132670 NaN NaN
252.479093944805 NaN NaN
253.081102421109 NaN NaN
253.824790305902 NaN NaN
254.931046199134 NaN NaN
256.474146982705 NaN NaN
258.187659542840

I think the result is meant to be soil profile temperature in Kelvins, so value (1) and (4) in bold seem very odd.

I am using PTCLM and interpolating from the input dataset clmi.I2000Clm50BgcCrop.2011-01-01.1.9x2.5_gx1v7_gl4_simyr2000_c190312.nc, something I used before which hasn't caused and issue like this on previous attempts.

Any help or pointers would be useful. I think I've maybe found the problem, but not sure how to solve it.
 

Attachments

  • cesm.log.614877.220816-160327.txt
    10.8 KB · Views: 0
  • lnd.log.614877.220816-160327.txt
    167.3 KB · Views: 1
  • version_info.txt
    8.2 KB · Views: 1
  • rof.log.614877.220816-160327.txt
    482 bytes · Views: 0
  • atm.log.614877.220816-160327.txt
    10.6 KB · Views: 1
  • cpl.log.614877.220816-160327.txt
    78.9 KB · Views: 1
  • config_compilers.txt
    41.6 KB · Views: 1
  • user_nl_clm.txt
    2.8 KB · Views: 1
  • env_build.txt
    13.9 KB · Views: 0
  • env_run.txt
    64.3 KB · Views: 1

oleson

Keith Oleson
CSEG and Liaisons
Staff member
One thing I see, although maybe not relevant to this specific problem, is that you have accelerated spinup on even though this appears to be a transient run. Is that intentional?
I guess I would look at some of the quantities that are used in the calculation of rvector. For example, a key quantity is the net heat flux into the soil/snow (hs_soil). The fact that you have an unrealistic rvector for what appears to be the top soil/snow layer can indicate something unrealistic with your atmospheric forcing, in particular, the solar or longwave radiation forcing. I'd also look at the thermal conductivity and heat capacity of the soil to see if it is realistic (derived from soil texture on the surface dataset).
From the atm log I see that this file is being read in:

/home/osw_gpny7/CESM_Work/cesm2_2_0/inputdata/ptclm-data/UNSET/CLM1PT_data/2045-12.nc 744

Is that correct? I'm not sure why it would be reading in 2045-12.nc since the simulation is starting at 2015. The directory "UNSET" seems odd also.
 
Top