Always send Nitrogen-deposition to surface components

[ekluzek]

In standard configurations both CTSM and the ocean model need to have Nitrogen-deposition used. The system is currently configured so that CTSM and POP assume that they have to provide ndep, but in some cases CAM sends ndep down to them (when WACCM is being used) -- and when it does they use it rather than providing it themselves. However, at the script level they don't know that it's being sent down so normally will abort if they don't have a file to read ndep setup. In the case when CAM IS sending ndep to the surface components they don't need to abort, and we'd like a way for them to know they don't need to abort when setting up their namelists. The other bad thing about the current situation is that the surface components will set control variables for the ndep file -- that won't actually be used. In this setup they are dummy variables that a user might think matters -- but actually doesn't. So it's bad behavior (to abort) and it's bad documentation of the case. The surface components could query the compset -- but since whether ndep is sent is a run-time configurable variable for CAM -- that's NOT a good solution.

The long term best answer to this to ALWAYS send ndep down to the surface components from CAM. When WACCM is on it'll be prognostic, but for other configuration's it'll be prescribed from datasets coming from previous simulations.

Note this relates to: #102

CTSM issue that relates to this: ESCOMP/CTSM#946

[ekluzek]

A short term solution we propose is that an XML variable be set to signal that ndep is being sent from CAM. I propose something like:

ATM_SENDING_NDEP=TRUE

I propose using "ATM" rather than "CAM", because this same variable could be used by DATM to signal that it's sending ndep.

[ekluzek]

A longer term solution would be for CAM to ALWAYS send ndep no matter what configuration it's running. This likely would be to adopt the calls to shr_streams to read in the same data that CTSM has been using. This would also require that datm do the same thing. If something like ATM_SENDING_NDEP XML variable was added it could be used while we were in transition.

The philosophy behind this is that inherently Nitrogen-deposition is a physical flux from the atmosphere, so the atmosphere component should be the one that handles it -- rather than surface components.

[gold2718]

At the level where CAM sends ndep to the surface models, it is merely responding to what in in the driver namelist. That is, CAM has no idea that it is sending ndep until runtime. Therefore, I believe that the simplest solution is for the surface models to imitate what CAM does. The first step is to determine whether the nitrogen species are in the MCT attribute vector (cam_cpl_indices.F90):

    index_a2x_Faxa_nhx      = mct_avect_indexra(a2x,'Faxa_nhx',perrWith='quiet')
    index_a2x_Faxa_noy      = mct_avect_indexra(a2x,'Faxa_noy',perrWith='quiet')

Then, the model can make decisions on the result. For instance (from atm_import_export.F90):

          if (index_a2x_Faxa_nhx > 0 ) then
             !! Expect nhx from atmosphere model
          else
             !! Surface model needs to read nhx
          end if

I do not see how to implement @ekluzek's recommendation because the information is in the driver namelist and CAM does not read that.

[ekluzek]

@gold2718 I don't think that's quite true. The thing is that CAM is what SETS the drv_flds_in namelist. An awkward aspect of drv_flds_in is that both CAM and CLM can set things in it -- and then the coupler puts them together.

The suggestion you have for the code IS what we are doing inside of CTSM. But, CTSM is stopping in preview_namelists because it doesn't know it doesn't need to set the ndep file.

Does that explain it better?

[gold2718]

@ekluzek, yes, I understand that this property is added to CAM's version of drv_flds_in (line 3955 in build_namelist). CLM also does this. Then, the driver compares and combines these files (in write_drv_flds_in_file of buildnml) to produce the run-time versions.
So, I maintain that, before CAM's build-namelist is run (via buildnml), CAM has no idea if those fields will be included. Since we cannot have any order dependence on which component's buildnml goes first, I still think that the only way forward in the short term is for the surface models to decide at run time whether or not to read an emissions file (the else clause above).

Since CLM needs a filename if is to read a file (duh), I think that CLM's build-namelist will always have to specify one -- even if it may not be used.

[ekluzek]

OK, so I think what you are saying is that the conditions for which CAM is going to decide it's going to send ndep to the coupler are complex enough that we can't know it beforehand. So we have to treat it as a black-box and just see the end result, rather than being able to predict it beforehand. If we treat it as a blackbox there then isn't a way to signal to anything else that it's going to be sent.

As you point out, the only way around it would be for CTSM check on the drv_flds_in file from CAM, but that requires that CAM's buildnml goes first. Relying on order dependence would be fragile and would break anytime the order changed. The order has been that CAM goes first right now -- but we can't robustly depend on that order.

So at this point we don't have a proposal for a short term solution. The only workable solution is the long term one, of having CAM always send ndep in some form (either calculated or from data files).

[ekluzek]

And since there is no short term solution, that does tell me that the right solution is the long term one of ndep always coming from CAM. Otherwise we are stuck with the system having this odd behavior of aborting when it doesn't really need to as well as listing files that it doesn't really need to read.

So what are the chances of the long term solution happening? The good thing about it would be that it could just adopt the same stream reading that CTSM is currently using which is only a few hundred lines of code.

[gold2718]

OK, so I think what you are saying is that the conditions for which CAM is going to decide it's going to send ndep to the coupler are complex enough that we can't know it beforehand.

No, that is not what I am saying. What I am saying is that a user can insert or remove these items from user_nl_cam just before submitting a run, i.e., there is no way for CAM to know what the user did before build-namelist is called.

So at this point we don't have a proposal for a short term solution.

But I did make a proposal for a short-term solution! My first post in this conversation has a specific, actionable proposal. If this solution is not viable (e.g., because build-namelist cannot always configure in an ndep file as a backup), please address that.

[ekluzek]

@gold2718 OK one question and one restatement then.

First, if someone sets ndep_list to send nhx and noy in their user_nl_cam (for a case without chemistry) -- will it abort and tell the user it can't do that? Or will it just send zero's or NaNs? If so that is something that you might want to address in CAM. Note that CTSM doesn't check the values that's it's being sent from CAM. So it would happily run with zero's -- but that would affect the simulation. It would abort with NaN's though. So if it's sending NaN's I think that would be an OK way to operate.

Second, the restatement. As I had said we have adopted what you suggested. CTSM checks the nhx and noy indices and if set -- it sets the logical variable ndep_from_cpl to true. If true it does NOT read in the ndep file, but uses what's sent from the coupler. If false it DOES read the ndep file that was set on the namelist and uses it. So we've already implemented everything I see in your suggestion, right? Is there anything that I've missed?

[gold2718]

@ekluzek, responding to your second piece, if you have implemented everything I suggested, why is there still a problem? In the opening of the issue, you said:

However, at the script level they don't know that it's being sent down so normally will abort if they don't have a file to read ndep setup.

My suggestion includes CLM (and POP?) having a default ndep file that is always configured. If that is not currently the case, can it be added? If not, can the code set the fluxes to zero if there is no file and the data is not coming from the coupler?

[gold2718]

@ekluzek, to address your second point, yes, the nitrogen quantities are initialized to zero. If chemistry is not running, those quantities are not modified so the surface should receive zero.
While that may not result in a valid simulation, we cannot control everything the user is doing.

In the long term, the plan is to solve issues such as this with a combination CCPP analysis and run-time NUOPC negotiation, however, this is a CESM3 target.

We may be able to implement your 'longer term solution' in CESM2, however, that will have to be scheduled and prioritized in AMP.

[fvitt]

It appears that if ndep_list is set and the atm chemistry does not include the required nitrogen species (or no chemistry) then the nitrogen fluxes sent to the cplr will be zeros.

[ekluzek]

@gold2718 that's something we explicitly decided that we would NOT do. I actually originally configured CTSM so that it would use the closest ndep file it knew about. But, we decided that's problematic -- because it's silently doing the wrong thing and not telling you about it. So, for example, you ask for SSP5-3.4 and under the covers it gives you the ndep file for SSP5-8.5. Now maybe it tells you that in log files or the namelist -- but if it doesn't do something drastic (like abort) it's easy to miss. I could also configure it so that it's given a dummy file that it knows it should never read (call it something like never_read_this_ndep_file.nc). In that case it would abort if it's trying to read it and ndep_from_cpl==F. But, then it's aborting when the model is running rather than being warned before hand. A good goal in behavior is for the model to let you know something's wrong as soon as it can be detected. So it's best if it tells you at case setup or preview_namelist time.

[ekluzek]

@gold2718 and @fvitt thanks for clarifying the behavior. Possibly CTSM should also check the values then and if they are all identically zero we should abort.