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

namelist control of switchdim_flag

thoar

New Member
I am creating (vector) history files with variables on a different timescale than those in the restart. Some of the variables are transposed between the two, which complicates the logic of my programming. There is a 'switchdim_flag' on the restart variables to help with the interpretation - I get it. I have searched the documentation and have not been able to find a namelist variable to control how the variables are written out. This seems to be restricted to variables with multiple levels. Historically, the level dimension varied fastest in the restart files, the vector-format history files have the column varying fastest. I do not want to change the order of the restart files - that seems like trouble - but changing the order of the history file variables might be possible. Any help?

For example, in a restart file (as output by 'ncdump):


Code:
double litr1n_vr(column, levgrnd) ;
                litr1n_vr:long_name = "" ;
                litr1n_vr:units = "" ;
                litr1n_vr:interpinic_flag = 1 ;
                litr1n_vr:interpinic_flag_meanings = "1=nearest neighbor, 2=copy directly, 3=skip, 4=area" ;
                litr1n_vr:varnames_on_old_files = "litr1n_vr" ;
                litr1n_vr:switchdim_flag = 1 ;
                litr1n_vr:switchdim_flag_values = 0, 1 ;
                litr1n_vr:switchdim_flag_is_0 = "1st and 2nd dims are same as model representation" ;
                litr1n_vr:switchdim_flag_is_1 = "1st and 2nd dims are switched from model representation" ;
                litr1n_vr:_FillValue = 1.e+36 ;
                litr1n_vr:missing_value = 1.e+36 ;

And in the vector-format history file:


Code:
float LITR1N_vr(time, levdcmp, column) ;
                LITR1N_vr:long_name = "LITR1 N (vertically resolved)" ;
                LITR1N_vr:units = "gN/m^3" ;
                LITR1N_vr:cell_methods = "time: mean" ;
                LITR1N_vr:_FillValue = 1.e+36f ;
                LITR1N_vr:missing_value = 1.e+36f ;
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
I'm not aware of any easy way to change the dimension order in the history files. Perhaps @erik or @sacks would know for sure?
 

thoar

New Member
Thanks Keith ... thinking about it a bit more ... the switchdim_flag is on the restart files, and it indicates is it switched from model representation. So it seems the restart files are transposed from the model representation, and they are the variables with the flag ... so if there is a namelist option to use the model representation for the restart files, it might not be such a bad idea ...
 

oleson

Keith Oleson
CSEG and Liaisons
Staff member
Right, a namelist option to use the model representation for the restart files.
Could you file a github issue with an explanation of your request and what science such an option might support?
That would bring it to the attention of our software engineers.

Just click on "New Issue" here:


and fill out the required information.
Maybe label it as "tag: enh - new science"?
 

sacks

Bill Sacks
CSEG and Liaisons
Staff member
I just wanted to confirm that, as far as I know, there is no easy way to change this behavior currently, either on the restart file or history file. I don't know the history of why switchdim exists on the restart file, but I could imagine unintended consequences of changing this (init_interp comes to mind as a possible thing that would break). Adding a 'switchdim' capability to the history variables is probably feasible, but would take some investigation.

That's all to say: while you should feel free to open an issue, I'm not sure realistically when we'd have a chance to address it. If it's not too hard to work around this on your end, that might be the best way forward.
 
Top