init_coupling for uncoupled runs

[cbegeman]

It seems to me that init_coupling, which is called from palm.f90, does not need to be called for uncoupled runs. Do you see any reason why I shouldn't add a line to only call this function if the coupling mode is not uncoupled?

I am motivated to do so because when the totalview debugger is used, it gets hung up on the standard input method of getting the coupling mode. Another solution to this problem (I think) would be to uncomment the method "get_environment_variable".

@qingli411 @vanroekel - perhaps you have thoughts about this since you may be more familiar with coupled runs?

[qingli411]

@cbegeman I think PALM use init_coupling to determine the run mode so I don't think the variable coupling_mode is set before calling 'init_coupling' that you can use to conditionally call init_coupling. But I think one solution is to hard code the file name to read in init_coupling to avoid read from standard input, just like other input files. I'm not sure why PALM uses standard input here... What do you think Luke? @vanroekel

[cbegeman]

@qingli411 I see, w.r.t. coupling_mode is default 'uncoupled' until after init_coupling. What file name are you thinking of to read in?

[qingli411]

@cbegeman Right now it reads in standard input from runfile, so maybe RUNFILE or RUNIN? I don't know... Whatever the file name, we will also need to modify palm_simple_run and RUN.cmd.*.

[vanroekel]

@cbegeman the coupling mode is grabbed in the mpirun command from runfile Instead of grabbing this parameter from standard_input, you could hardcode the read of runfile in init_coupling. However, you'd have to also add an appropriate open statement. I think the better option is to make this a namelist option and remove this setting from Run.cmd.*

[vanroekel]

Also, I forgot to mention that 'uncoupled' is the default until init_coupling is called.

[cbegeman]

Thanks, @qingli411 and @vanroekel. It seems very straightforward to set coupling_mode (which already exists in modules) as a namelist parameter. The other two variables that it reads in (to bc_data(1) and bc_data(2), are $cores_atmos / $openmp_threads and $cores_ocean / $openmp_threads as specified in palm_simple_run. It seems like we would want these variables to be assigned in run_script_lanl rather than the namelist file, right?

[qingli411]

@cbegeman @vanroekel I don't think it's a good idea to make coupling_mode a standard namelist option in PARIN because in the coupled mode the 'atmosphere nodes' and 'ocean nodes' read two separate namelists PARIN and PARIN_O. This happens after init_coupling which assigns the 'atmosphere nodes' and 'ocean nodes'.

[vanroekel]

good point @qingli411. Given this we should just read runfile directly into the model and not take it from standard in.

[cbegeman]

Great. Thanks for the discussion. I'm happy to make this change to reading runfile directly.

[cbegeman]

@qingli411 @vanroekel Can either of you share the parameter file(s) that you use for a coupled run? I see something about PARIN and PARIN_O in the documentation, so maybe this is 2 files rather than one. I want to make sure the runfile read works for both uncoupled and coupled cases. Thanks!

[qingli411]

@cbegeman You can use test_coupled_p3d and test_coupled_o_p3d in the master branch for testing. If you run the model in coupled mode it will look for two namelists, one ends with '_p3d' the other ends with '_o_p3d', and rename them to PARIN and PARIN_O in the run directory.

[xylar]

addressed by #12, correct?

[xylar]

If not, feel free to reopen.