[buckngnr11]

Hi everyone, this might be hard to answer on here, but I'm hoping someone can help me out. I am simulating deposition on a surface. I deliver particles in Fluent, predict whether they stick or rebound from a surface, and then approximate the amount of volume the particles would take up on the surface, and use define grid motion to displace the wall boundary and simulate deposit growth. I use Define_Grid_Motion for this. I am able to do this successfully for one iteration. The mesh moves as expected and then I run flow iterations until the solution converges on the new, adjusted mesh. I then run particles through the updated flow. In the process of calculating the mass and volume of deposit in each cell, I know get a SIGSEGV error that crashes fluent that didn't occur in the first iteration. I attached an image of the portion of the code that appears to fail. If I delete the three lines where the Avgnorm components are added, the UDF works. The minute these three lines are added, I get the error and crash. This is simply a += operation that doesn't call any memory, so I don't understand why this is happening. The x-comp, y-comp, and z-comp in the loop are calculated perfectly fine, so I'm confused why dividing each by three and summing them in the loop would be an issue. I will note that when I recalculate the flow solution, it saves a new .ip file that I think is interpolated flow data. Another very odd thing I noticed. If I remove the three problematic lines and run the UDF, it works. Then if I add the lines back in and run it will calculate and work correctly. The issue only emerges when I run the particle tracks or clear all of the UDF's, and then try to run the entire code at once, with the problematic section included. This makes no sense to me.

[vinerm]

You are absolutely correct in stating that a += statement should not cause a trouble. And these statements are certainly not causing any trouble. The issue most likely is with the UDMs. The statements make use the values fetched from the UDMs. Do you have a part of the code that initializes all the UDMs to some values before using those? Or do you initialize these UDMs via patch or Initialize before starting the simulation? If not, do that before compiling the code. To debug the code, try replacing the xcomp, ycomp, and zcomp in those equations with some constant values.

[buckngnr11]

Thanks for the reply. I have an executable that I run that loops through every UDM and clears the values. I run this and then plot the UDM and make sure everything is cleared (this works). Then, those UDM's are filled in with the DPM UDF. I check these after I run the particles, and the UDM values are all there and all work correctly. The three UDM's called into xcomp, ycomp, and zcomp are all working fine. Like I said what is very unusual to me, is that if I get rid of the lines that calculate the Avgnorms, there is no failure. The xcomp, ycomp, and zcomp call the UDM just fine. It's only when I add those lines back in that there is an issue. Any chance that this could be due to a memory allocation issue?

[buckngnr11]

Okay I think I might know where the issue is. After moving the mesh, I then run the flow calculation, but I realized that after the iterations are run, the console says "Registering UDFsource and Registering UDFLib". The particle tracking stats also appear even though I did not run the particle tracks. Does this have something to do with the profle update interval option in the calculation settings? If this is set to the default (1), is the UDF calculating every iteration? If I want to stop the particle tracks from automatically running and also stop the UDF from calculating until I hit execute_on_demand, how do I achieve this?

[vinerm]

Particle are tracked as per user's DPM setup. If you do not want those to be tracked, either disable Interaction with Continuous Phase under DPM or increase the number of Continuous Phase Iterations to a high number. As far as Execute on Demand is concerned, you may use DEFINE_ON_DEMAND instead of whatever DEFINE_ macro you are using right now.