ENH: added option to control log frequency of lagrangian calculations

Summary

Cross ref: EP#1945

Lagrangian cloud calculations can generate significant amounts of reporting, e.g.

Solving2-D cloud reactingCloud1
Cloud: reactingCloud1
    Current number of parcels       = 994
    Current mass in system          = 0.009735873844
    Linear momentum                 = (0.0001652067978 0.0001039875528 0)
   |Linear momentum|                = 0.0001952093676
    Linear kinetic energy           = 0.0001660812145
    Average particle per parcel     = 19.21387643
    Injector model1:
      - parcels added               = 994
      - mass introduced             = 0.01
    Parcel fate: system (number, mass)
      - escape                      = 0, 0
    Parcel fate: patch (walls|cyc.*) (number, mass)
      - escape                      = 0, 0
      - stick                       = 0, 0
    Parcel fate: patch (inlet|outlet) (number, mass)
      - escape                      = 0, 0
      - stick                       = 0, 0
    Temperature min/max             = 275.039299, 275.4193813
    Mass transfer phase change      = 0.000264126156
    Mass transfer devolatilisation  = 0
    Mass transfer surface reaction  = 0

If multiple injectors and/or more interaction patches are present, the quantity of output information can increase dramatically.

For some workflows it can be beneficial to reduce the amount of output by reporting this data every n time steps instead of every step.

Details of new models (If applicable)

Added an optional logFrequency keyword to the cloud solution input dictionary, e.g. in the <case>/constant/*CloudProperties

solution
{
    active          true;
    coupled         false;
    transient       yes;
    cellValueSourceCorrection off;
    maxCo           0.3;

    logFrequency    3; // <--- NEW ENTRY

    ...
}

The value is set to 1 by default to maintain backwards compatibility.

Risks

• Multiple small changes across the code - should be low risk.
• use of Log_ vs Log annoying but needed for use in templated code - suggestions welcome

changed milestone to %v2212

added enhancement feature labels

requested review from @kuti

assigned to @mark

minor: updating the Copyright-year statements.

• linux64ClangDPInt32Opt (clang13)
• linux64GccDPInt32Opt
• linux64GccSPDPInt64Debug
• Alltest: No new error

Although the Log macro is convenient, I never really liked how it worked with a bare log variable being expected. I see that we need to have a this-> for templated code, but in that case I guess we could also have that variable be called log_ instead to make it clearer. Macro name as LogThis ?

On the other hand, most cases where we are currently using the Log macro are very likely to be within non-static methods, in which case this->log will still work and use the static log. Could then potentially just redefine the Log macro instead.

resolved all threads

approved this merge request

approved this merge request

Still don't like the Log_ junk, but no better ideas...

@andy - anything left to go in?

resolved all threads

@andy - rebasing on GUI seems to be stalled. Can you rebase locally and force-update?

added 33 commits

• 3c229715...8afd6ff7 - 27 commits from branch develop
• 161fab8d - COMP: messageStream - use this->log
• b94bf625 - ENH: cloudSolution - added log/Info output control
• 1f393aef - ENH: subModelBase - added log data member
• 9c9088f1 - ENH: CloudSubModelBase - added info() function to set log flag
• d8f33c62 - ENH: lagrangian intermediate library - added logging controls
• 3a429894 - STYLE: lagrangian intermediate library - renamed log_ to logToFile_ to...

Compare with previous version

mentioned in commit 9e6123b5

merged