Logging and parameters best practice

[mordech3@post_tau_ac_il]

Hi,I'm about to add some specific feature to the atmosphere component in CESM and would like to know the following:- Is there a best practice for logging output from a CESM component? Calling a specific function? The purpose is just to write flow details while developing and debugging.- Is there a best practice to add a parameter to component's XML configuration and access its value in runtime? The purpose is to control execution flow and some for physical significance.The idea is to make things in the proper way CESM was designed, without creating not supported code. On the other hand, if there is a developer reference to CESM I'd like to know and use it if pointed by others.Thanks, Moti.

 

[santos]

"Is there a best practice for logging output from a CESM component? Calling a specific function? The purpose is just to write flow details while developing and debugging."Currently, in CAM, the best practice is to write to the unit number "iulog" (from the module "cam_logfile"). If the output is only needed once for all process (e.g. logging which options were used during initialization), you should use "if (masterproc)" to ensure that only the master process prints (masterproc is from the module "spmd_utils").The output will show up in the general log or stdout for standalone CAM runs. For CESM runs, it will show up in the cesm.log file for most processes, but in atm.log for the master process."Is there a best practice to add a parameter to component's XML configuration and access its value in runtime?"I'm a bit confused. Do you mean that you want to add an option to "configure" and then have the model see it at run time? Or do you mean that you just want to add a namelist variable (e.g. to namelist_definition.xml and namelist_defaults_cam.xml)?"On the other hand, if there is a developer reference to CESM I'd like to know and use it if pointed by others."I believe that there was such a thing, but it's probably out of date. I actually don't know where it is, so I'd be interested to know if anyone can point me to it as well...

 

[njn01]

First of all, thank you for thinking about best practices in your developments! 
As to your question, after quick search, I found developer's guideline links on various working groups' web pages (OMWG, LMWG, and AMWG for starters).  There's a pull-down menu off from the CESM web page that will take you to these pages, so I would recommend you take a look there. 

 

[mordech3@post_tau_ac_il]

Hi Sean, NJN,Thanks for your comments, that's really helpful and in the form I was looking for.Sean, as for the most of the questions that's a good advice (either per process, or globally, there are cases where I'd like that or the other and better experiment to find the difference).Regarding the configuration, maybe I can elaborate a little more about the issue and it can serve as an example.I'm about to port some of CAM code to GPU using OpenCL in Fortran. An effort was already done to bring the OpenCL API available to Fortran in native mode (no C/C++ involved, pure Fortran), a library called CLFORTRAN that should be released soon as LGPL (licensing model already approved legally, but there are some more formal actions to be taken).The idea with the configuration parameter is to allow the user decide whether to enable GPU support/routines for a specific case or not.
Currently for me mostly, targeting development purposes (and still making no runtime changes for ordinary users of the installation), but in the future as a selection parameter for production runtime. When setting the value of "GPU_SUPPORT"/"USE_GPU" (or so) to 1, the runtime will use the GPU routines etc.There are more challanges of course involved, but only to address some basic technical barriers.NJN, I had a chance to find the documents you mentioned and they do provide valuable information, but mostly in general and administration (coding styles etc.). I couldn't find more technical topics like the knowledge Sean shared about each component or CESM.
Even if there is no wiki with such details, I hope that the forum can be a good source for any future developer involved in such activity.Thanks,
Moti.

 

[jedwards]

Hi Moti,
Wouldn't GPU_SUPPORT be a build time and not a runtime option?   It would cause the opencl code to be compiled or not, right?    For an example of a variable used in this way look in the env_build.xml and the DEBUG variable - DEBUG flags are optionally set in the Macros file based on the value of this variable and the settings in Machines/config_compilers.xml Jim

 

[santos]

I see. In this case, you would want to create a configure option, which would define some flag (like "USE_OPENCL") and add to the linker flags. (I would not use a generic "GPU" flag, because it might cause some confusion if other methods like CUDA or OpenACC end up being used in the future.)I would look at how we define the COSP options in models/atm/cam/bld/config_files/definition.xml and the configure script itself in models/atm/cam/bld/configure. Your case is easier than COSP, because presumably CLFORTRAN is already built on the system and so you don't have to put in any logic to build it. This is probably sufficient to get a standalone CAM case working.Getting this working in CESM is a little different (you would have to edit the CESM Makefile to add CLFORTRAN to the linking flags)? The only thing is, I'm not sure what the "best practice" here is. I think that the right approach would be to add a flag to env_build to control this (sort of like USE_ESMF_LIB is implemented).

 

[mordech3@post_tau_ac_il]

In fact, both of you (Jim and Sean) are correct.CLFORTRAN is in the form of a Fortran module, but will be compiled with CESM every time to ensure compiler compatibility with the rest of CESM source code.Indeed, a build flag is required to allow the interfacing Fortran functions access the native OpenCL library functionality, and also include the GPU developed modules + OpenCL source.However, runtime configuration is also necessary, so we can control a specific run and decide whether to use the original CPU code and revert to GPU and vice versa, to check performance, accuracy etc. (by only changing a flag and not compiling the entire case again).It will take a while to have it into a more complete form in CESM environment and probably at first I'll check the implications locally with CAM (modified code) and later investigate the implications to make it more globally aware (CESM scale).In any case, it will have to involve some more work and consideration from the official CESM maintainers, since employing GPUs in cluster scale for CESM with MPI is not an intuitive task at all and should be done carefuly (avoiding resource conflicts/allocation etc.). We've done some preliminary analysis on that, but there is more to address.Thanks again,Moti.