Keep only user_nl_blom-changed values for namelist /bgcparams/

[jmaerz]

This is a suggestion on how to tackle the issue on hard-coded versus xml-coded parameters. Only parameters changed through user_nl_blom will be kept to write into the nml-group /bgcparams/. All other groups are not affected with this approach and it is minimally invasive. I tested with some parameters set to None in the namelist_definition_blom.xml (to avoid confusions) and it works as well. Model build works as well for ocean only setups and coupled simulations (tested until ./case.build).

This means that essentially all variables can be defined in the Fortran part (and with None-value in the namelist_definition_blom.xml and only tuning parameters set via the user_nl_blom will be forwarded to ocn_in. No further preprocessor-flag is required to distinguish between coupled or standalone runs and in case that at some point we decide that the xml-way is the only way, all infrastructure is already there - only the values need to be once transferred.

Closes #327

[JorgSchwinger]

For now this solution seems good to me. In addition we could remove the default values from the namelist_definition_blom.xml (since they are not used) to avoid confusion.

[jmaerz]

Done. I also tested this approach via ./preview_namelists and it still works as expected (both, ocean only and coupled setups), also when all bgcparams parameter are set to None in the xml-file.

[mvertens]

@jmaerz - this is a very nice implementation. However, I still feel that this is not the best way to proceed. You will need to look in two places to see namelist setting - the code for namelist values that do not appear and the actual namelist file. In fact you have no idea from looking at the namelist file what the set of namelist parameters are. Ultimately, this will lead in my opinion to a less robust way to carry out experiments. I think that the implementation proposed by @gold2718 would be my choice. However, it is of course up to the iHAMOCC group to decide what they want to do - and if this is the solution it wants to adopt. If this is chosen - I am fine with the implementation.

[mvertens]

@jmaerz - I just looked at the PR again and see that you are proposing this as just an interim solution. If this is the case and the original implementation will be ultimately used - I think this approach is fine. However, longer term I think we should implement the proposed solution suggested by @gold2718.