getFrictionLoads User Function resulting in segmentation fault error

[alden]

Hi all, I was working on adding frictional heating into a 2D transient ice sheet model, and when I try to evaluate the "getFrictionLoads" User function, I get thrown this error. In other words, the simulation runs fine until I attempt a model run with this additional function.

TemperateIceSolver (temp): -------------------------------------
TemperateIceSolver (temp): temp iteration no. 1 of 100
TemperateIceSolver (temp): -------------------------------------
TemperateIceSolver (temp):
TemperateIceSolver (temp): Starting Assembly...
0 : Max/min values Temperature: 260.00000000000000 / 260.00000000000000

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x7F3E8AE57E08
#1 0x7F3E8AE56F90
#2 0x7F3E8AAA74AF
#3 0x7F3E8B1C2108
#4 0x7F3E8B1C4F80
#5 0x7F3E8B517038
#6 0x7F3E8B5170E6
#7 0x7F3E4F11FFC1
#8 0x7F3E8B1E302D
#9 0x7F3E8B33A446
#10 0x7F3E8B36D157
#11 0x7F3E8B529E9A
#12 0x7F3E4D48C906
#13 0x7F3E8B3BFE5F
#14 0x7F3E8B3D5429
#15 0x7F3E8B3D6CF3
#16 0x7F3E8B3D8949
#17 0x7F3E8B5F48ED
#18 0x4010F5 in MAIN__ at Solver.F90:57
Segmentation fault (core dumped)

I was wondering if there is an easy way around this problem.

Thanks!

[alden]

I just thought I'd post an update now that I've spent some more time on this issue.

I ran the FrictionHeat test in elmerice/Tests, and I found that the frictional load user function works fine.

I then ran the ArucoElmer Ice flow and temperature coupling example from the 2016 online course. This example had the same failure as my previous attempt, and removal of the friction load calculation allowed for the simulation to run (albeit without frictional heating).

One large difference between the Friction heat test and ArcuroElmer/my model is a 2D mesh instead of a 3D mesh. I was wondering if this user function could be having trouble with the 2D mesh?

Thanks.

[alden]

Hi all again, just posting to say that I appear to have resolved the problem. I made the bed a separate body as was done in the test friction heating test. If anyone has any thoughts into why this makes a difference I would be interested to hear.

Thanks!

[tzwinger]

Hello,
the issue lies within line 184 in USF_GetFrictionHeating.F90

Code: Select all

  Equation => GetEquation()

Which picks the current element and tries to assign an Equation from it. In case the boundary element the USF is executed on has no assigned body (plus an Equation to be applied to it), this will be an unassigned pointer and hence crash.

Tracing the further use of this pointer, I see that it is used solely to pick up an the name for the Flow Solution and its residual values. I suggest that we either move that inquiry to the parent element (which of course has then to be inquired) or we abandon the possibility to deviate from the default name (="Flow Solution")

Regards,
Thomas

[fgillet]

Hello,
code is ok in getFrictionLoads if Equation is not assigned, which should be the case if element do not belong to a body with a given equation?

I think this could be fixed in GetEquationId (DefUtils.F90) which should return with Found=.False. if body_id < 1 ?

Cheers
Fab

[tzwinger]

Hi,
I think the core issue here is that you want to inquire something from an Equation section out of an USF that not directly relates to one (as else it'll be a Solver). In other words: there is no direct relation between USF's and Equation section.

In the working example the only reason why it did not crash was that the ForceToStress solver was run on the boundary body (and hence provided a Equation pointer) - but that is pure coincidence. If the output is not included, there would be no need for this extra body. The most consistent way would be to inherit the Equation (if we insist on using it) from the calling solver (i.e. parent element).

Thomas

[fgillet]

Hi Thomas,
Yes I agree that core issue is with the GetEquation in the USF and this should be changed.

However, this does not crash for me even if I don't have a body for the bed; and I think this is why it has been un-noticed so far, espacially when the Aruco test case was designed.
So to play safe it is maybe better to also fix the issue in GetEquationId to avoid a seg. fault in case an Equation is inquired from a BC with no body associated.

[tzwinger]

I pushed a version to elmerice-branch that derives valid Equation from the parent element. Issues might occur on body-body boundaries, but the EISMINT case should now run without the extra body on the boundary.

Regards,
Thomas

[alden]

Thanks for the help! The simulation works fine without the third body for the bed now.