Numerical precision in ParsedFunctions

[mangerij]

Check these boxes if you have followed the posting rules.

• I have consulted the Posting Guidelines.
• I have searched the Discussions Forum and MOOSE Framework Troubleshooting and have not found what I was looking for
• Q&A Getting Started is the most appropriate category for my question (trouble installing, beginner user, ...)

Issue or question about MOOSE

I am suspecting that there could be some issues with the Parsed function and round-off.

I have another simulation where the output is fit to a Fourier expansion. I then use this fit as a function in a MOOSE calculation. The ParsedAux expression is something like

[./b_xy]
    type = ParsedAux
    variable = b_moire_exy
    use_xyzt = true
    expression = 'if(z<-${sep}, 0.01*(0.0034882299544280147-0.009912186508082784*cos(351.90503832638063-3.5355339059327378*x-3.5355339059327378*y)-0.005193928363003325*cos(126.85871466072412+3.5355339059327378*x-3.5355339059327378*y)+...'
  [../]

The Fourier fit only has one frequency - up to 7th order so it is easy to figure out the minimum x,y coordinates for a strictly periodic computational domain.

However, when I visualize this field with ParaView and replicate the periodic domain many times, I see that it does not really match up. See below.

Could it be a visualization error from round-off? I.e. the box spans x,y = 1.0 to x,y = 4.442882938158366. So maybe ParaView is rounding off where to translate the periodic image... Does anyone know? Or should I suspect that ParsedAux also does some rounding?

Thanks!

(Optional) code in question / simulation log / errors

No response

Encountering Errors? Please include diagnostic output

No response

[GiudGiud]

Hello

So maybe ParaView is rounding off where to translate the periodic image...

You could check with a simple profile? Like cos

Or should I suspect that ParsedAux also does some rounding?

Parsed expresssions are optimized by fparser which can perform round offs. You can turn it off to check with the disable_fpoptimizer parameter
https://mooseframework.inl.gov/source/auxkernels/ParsedAux.html

[mangerij]

I have verified that this is not a visualization issue from ParaView nor due to the fpoptimizer.
Seems to be from somewhere else in my calculation.
I'll mark this as an answer since this was precisely my question. Thanks!

[GiudGiud]

maybe in the output? what are you using? nodal variables?

[mangerij]

Yes. The calculation uses Nodal variables.

I also checked if this was due to used_displaced_mesh = true (it is an elastic problem), convergence and my use of level 1 hanging nodes or not.

I am using block restriction with euler angle rotations in both blocks that are both periodic along XY. I checked if this was the origin of the slight discrepancy - i.e. if I do not do any rotations, I still get the issue. It is a big mystery, but I am going to get around it by loading the postprocessed information from ParaView and numerically smoothing for visualization purposes...