Change U to use custom code for parabolic profile

[Ferraan]

Change the inlet velocity profile so as not to use the swak4foam external library with the groovyBC inlet conditions.

[davidscn]

This is an outstanding contribution. I have and had trouble compiling groovyBC for the latest OpenFOAM 2306. The boundary condition type here is compiled (and potentially reloaded) at runtime and elides the dependency . @Ferraan do you have any idea about the OpenFOAM versions, which support this feature?

[Ferraan]

Hi, I have tested it with OpenFOAM.org versions 9, 10, 11 and OpenFOAM.com versions 2206 and 2306 and it works in all of them. By the way I forgot to add that you should also remove the libs ( "libgroovyBC.so" ) ; line from the controlDict. I don't know if it can be added to this PR or a nwe one should be created.

[davidscn]

Hi, I have tested it with OpenFOAM.org versions 9, 10, 11 and OpenFOAM.com versions 2206 and 2306 and it works in all of them.

That's sufficient.

By the way I forgot to add that you should also remove the libs ( "libgroovyBC.so" ) ; line from the controlDict. I don't know if it can be added to this PR or a nwe one should be created.

You can still add it here, if you want. Our partitioned-heat-conduction tutorial also uses groovyBC. I need to check whether I can also get rid of it there using something similar. If yes, we can remove libgroovyBC entirely as a dependency, which requires some documentation updates on our website and the VM.

[Ferraan]

Hi, I've changed the partitioned-heat-conduction case to remove GroovyBC. By the way, why does the case use this expression:
$$1+x^2+3y^2+1.3t$$
when in the original paper [Quasi-Newton waveform iteration for partitioned surface-coupled multiphysics applications.] it uses the following expression:
$$1+x^2+3y^2+1.2t$$

[davidscn]

Hi, I've changed the partitioned-heat-conduction case to remove GroovyBC. By the way, why does the case use this expression: 1+x2+3y2+1.3t when in the original paper [Quasi-Newton waveform iteration for partitioned surface-coupled multiphysics applications.] it uses the following expression: 1+x2+3y2+1.2t

There was some confusion, because we had in the tutorials for some reasons 1.3t. However, we switched it back to be consistent with the paper you are referring to. That's also the reason for the merge conflicts here. Please resolve the merge conflicts (in essence taking over your changes with dt=1.2), then we are good to go. Thanks a lot.

[davidscn]

Actually, I am working now anyway on this case, so let me just resolve the conflict and merge.

[MakisH]

This is very very useful for us, since we remove a required dependency that is not very easy to get or sustainably developed at the moment. Thanks a lot!

We should still add a changelog entry / mention this in the changelog.

[Ferraan]

Hi, first of all when I was testing the internalField value it did not seem to affect the results, although I have no clue as to why, that's why I removed the line.
However, I created a new commit with a possible solution, but currently I do not have time to test it so I'm not sure if it works.
Finally, I've seen that in openFoam.com versions there is also the option to use "setExprFields" to set the initial condition in the internal domain, which might be easier to use but there is no support in the openFoam.org version.
I'm glad to help the project and help eliminate the dependencies!

[MakisH]

The updated initial condition setup works for me on v2312 and I do get a state close to the final solution after the first time step. I don't know how to export the initial field, so I set writeControl timeStep; writeInterval 1;.

I did not compare with previous results.

[davidscn]

Technically, everything works. I ran the partitioned-heat case now using #449 and got an error, which is substantially bigger.

For the Dirichlet solver, I get

Error metrics at t = 1s:
l2 error (sqrt(sum(err^2)/n)):		0.000782553
Maximum absolute error (max(err)):	0.00497633
Global absolute error (sum(err^2)):	0.00612389

(to be compared against the metrics reported in #449). I did some experiments, and surprisingly, the difference stem from the boundary condition, whereas the changes in the initial condition/internal field are just fine. Any clue where this could stem from?

[davidscn]

The problem here is the time-dependency of the boundary condition. The boundary condition is only evaluated before the very first time-step and after every time-step. Hence, the absolute time is lagging behind or (if a time window was completed) shows the time of the previous time-step.
As a remedy, one could use nonOrthogonalCorrectors (e.g. 3), as before each correction step, the boundary condition is updated. This gives then the correct error metrics as reported in #449. A clean solution would, however, either access the correct time value or evaluate the boundary condition at the correct time.

@MakisH any opinion about this?

[MakisH]

The problem here is the time-dependency of the boundary condition. The boundary condition is only evaluated before the very first time-step and after every time-step. Hence, the absolute time is lagging behind or (if a time window was completed) shows the time of the previous time-step.

But this means that this is an issue with the implementation of the coded boundary condition in OpenFOAM, correct?

Is this really a difference between groovyBC and codedFixedValue? I would expect both to be evaluated at the same time. It is probably that the groovyBC time() function is implemented differently than just accessing this->db().time().value();.

As a remedy, one could use nonOrthogonalCorrectors (e.g. 3), as before each correction step, the boundary condition is updated. This gives then the correct error metrics as reported in #449.

Let's not hack using seemingly unneeded elements. We could, of course, document this workaround.

A clean solution would, however, either access the correct time value

Is there an oldTime or oldValue we could use? With a quick search in the Doxygen pages, I could not find anything like that.

or evaluate the boundary condition at the correct time.

Remember that, as we are going through the function objects interface, the time we set the boundary conditions on the coupling interface may also be one step behind. But I think we already checked that at some point, no? Otherwise, this could be a manifestation of this discrepancy.

[MakisH]

@davidscn what is your suggestion on how to proceed here? I think it would be nice to merge and release this in this cycle.

[davidscn]

@davidscn what is your suggestion on how to proceed here? I think it would be nice to merge and release this in this cycle.

Considering that the heatTransfer solver is anyway a custom solver of our own, we can trigger the boundary condition update in the right place, using correctBoundaryConditions(). groovyBC doesn't seem to rely on this mechanism. pimple(DyM)Foam is doing the right thing, i.e., updating the boundary condition before solving the velocity equations. I will merge here and fix the boundary condition update in a follow-up PR.

[davidscn]

I had to resolve the merge conflicts locally, as they were to big. I squashed the commits and committed them to develop. Unfortunately, GitHub doesn't recognize here. @Ferraan is still the author of the commits (cf a688fa7). Given that it is now in develop I will close the PR and open a follow-up for some clean-up. Thanks again for this nice contribution @Ferraan.