Efficient run-time postprocessing: combination of swak4foam and solver modification?
 

Dear Foamers,

similar to this thread on how to calculate a turbulent heat flux <u'T'>, where <...> denotes a local time average, I plan to calculate the vertical turbulent momentum fluxes <w'u'> and <w'v'>. Plus, the vertical total momentum fluxes <wu> and <wv>. This is in order to monitor OpenFOAM LES of the atmospheric boundary layer.

I want to output these data not for the total domain but only as one-dimensional vertical profiles at say ten or twenty locations within the simulation domain, e.g. for postprocessing with XmGrace.

My question is which is the best way to efficiently calculate and output these data.

Since I have a modified solver anyway, it would be possible to code the time averaging according to this post for U as well as the products wu and wv. The time-averages <w'u'> and <w'v'> could be calculated in a similar manner in the solver. But I would expect that this wastes CPU time as well as RAM since the output is actually only needed for ten to twenty one-dimensional vertical profiles.

So, is there a way to calculate these data more efficiently only where output is needed? I have a vague feeling that swak4foam may accomplish this. If so, how?

And is there any elegant way to combine the definition of ten, twenty vertical profiles? If I use ten, twenty different sampledSet, my controlDict would become quite long.

Looking forward to hear your advices,
Marcus

"10 or 20 points" screams "sampledSet". With the swakExpression-FunctionObject and the valueType "set" you can do calculations on such a sampledSet (see the examples for ...aeh ... examples). The only "problem" is that swakExpression wants to condense the result to single values (sum, average, etc). There is a functionObject dumpSwakExpression that dumps all the values. Have a look at it: the file format is a bit ... well ... you'll have to find out which column is which point for instance (that FO was only done as a quick fix)

Thank you, Bernhard.

Is there any chance that the compulsory condensation of swakExpression results to single values could become optional at some point in the future?

I must admit that I am a bit hesitant regarding the dumpSwakExpression approach. IMHO, if the columns in the output file are not labelled, it seems to be prone to human errors during further postprocessing. For example, columns may get mixed up later.

So, I am now considering to resort to the computationally less efficient combination of solver modifications (averaging and flux calculation) and the native OpenFOAM sampling functionality by declaring ten, twenty sampledSets.

No. One of the policies I have is to change semantics of things after the release only if there has been a bug or if it is a major improvement for the majority of the cases. Don't want to break existing cases by changes of swak (they already get broken by OF-releases)

Also having the "dump" as the default functionality is asking for trouble. Approx 2.7 days after release somebody will use it on an internalField, write it every timestep and complain that swak filled up his disk
If you have a static mesh then the order of the columns will not change. One thing you can do is have a "parallel" FO with the expression "pos()". That has the same order as your data and you can use that as the labels.

One of the reasons why there are no labels with dump is
a) that this must be implemented for every valueType separately
b) What should the label be? Position? Cell number?
c) the hardest part: what should be done if the entity changes its size, ordering? (for instance due to mesh motion or a sampledSurface of type isoSurface) Start a new file? Just write a new heading?