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

Memory overwrite issue??

Hi

I am having a strange problem getting CAM4 to run with some modifications I made to physpkg.F90. Some quick background first: In physpkg.F90, I read in a netcdf file containing
some additional heating values and I apply the additional heating. In the top of the routine, before the "contains" statement, I declare a couple of parameters and variables using the
"save" attribute. Here is the code of the stuff I added (right before the "contains" statement)

integer, parameter:: n_x = 96
integer, parameter:: n_y = 144
integer, parameter:: n_z = 26
integer, parameter:: n_ph = 26


real, save :: lh_global(n_x, n_y, n_z, n_ph) !latent heat including all the zeros for latitudes not forced with heating !CL

integer, dimension(n_ph), save :: month_to_start_heating, day_to_start_heating, month_to_stop_heating, day_to_stop_heating !CL
logical, dimension(n_ph), save :: do_heat !CL
integer, save :: ispinup=0, ijan=0, ifeb=48, nn !CL


Then in the subroutine phys_init, I read in the netcdf file and assign the heating values to a variable that I call lh_global. To do this, I use the routines
cam_pio_openfile, pio_inq_dimid, pio_inq_varid, pio_inquire_variable, pio_inquire_dimension, and pio_get_var.

Finally, in the subroutine phys_run2, I apply the forcing due to lh_global.

This is what happens. It compiles without problem. When I try to run it, it works only if I insert artificial print statements near the code where the values get read in. If I take out the
print statements, I get a segmentation fault error. When I put in print statements (something dumb like (print*,"hi")), it runs without problem. I cant for the life of me figure out
why the print statements make a difference at all unless there is some memory overwrite issue on one of the variables that I added. Or unless I declared stuff incorrectly. I can
attach or send you the modified version of physpkg.F90 that I use.

Any information you have would be much appreciated. I have spent weeks trying to figure this out…

Cara-Lyn
 

eaton

CSEG and Liaisons
Can you print out values of lh_global to verify that you've read in that field successfully?

If you verify that the data has been read successfully, then I'd suggest writing it back out to the history file. It will be easiest to do this if you write n_ph separate 3D fields. You should then be able to compare this output with your input and get a bit for bit match. That would verify that you are correctly mapping between the global field and the physics decomposition.

It may also help to accomplish either of the above steps if you turn on bounds checking flags during the compilation. You'll need to check the manual for the compiler you're using to determine the correct flags. They may already be present in the CAM makefile if you set the -debug option to configure. But we don't consistently set these flags for all compilers because they aren't always reliable.
 
Top