Monitor Points/Surfaces
 

Hello, everybody,
i would like to address a topic which i think has a high relevance for the cummunity, namely the definition of monitor points/surfaces during a transient calculation. When it comes to LES simulations, you don't want to store the output of the whole domain at each time step in order to perform transient analysis. Therefore it is possible to define monitor points. In my case, however, these are 100k+ points, which are arranged in several planes. I have followed different ways to do this as efficiently as possible:
1: import monitor surface points via TUI -> this is possible up to a number of 2000 points, but then it gets exponentially slower and is therefore not an option.
2. import stl surfaces and imprint them via /surface/imprint-surface/... -> this would destroy the structured arrangement of my data, which I could live with but even this approach is so slow that it is absolutely impractical.
3. the last solution is of course an implementation using UDF. I found a function for this (https://www.eureka.im/701.html), but it is from 2003 and I wonder if this is really the most efficient way to define such an output, especially since it is completely trivial in CFX using user interfaces? (I have not been able to get this solution to work! -> SIGSEV error!)
I hope that people who understand more of the material can help me and above all I hope that this is really just a mistake on my part, because I think that this would really be a weakness of the pre processing of fluent.

Monitor Points
 

For such a high number of data points, it is obvious for any tool to slow down. But the reason is not the tool, rather the machines I/O. For such a work, you need to have hard drive working at the speed of RAM, i.e., an SSD.

Even if you use UDF, it will be slow, however, the UDF will work for sure. Furthermore, if you want to write data only for a few variables, you may also go for option of writing cdat files from Fluent. This will store more data but will still be much smaller than Fluent's dat file.

SIGSEGV error implies that UDF is trying to access an unavailable memory. The specified UDF requires gradients of the field variables to be stored. By default, Fluent does not store those values. As mentioned in the Note, a command is required to be issued before running Fluent. If that is not issued, you will get segmentation violation error. This will also increase the RAM requirement because now you have many more matrices to be saved.

Hello, vinerm,
first of all I would like to thank you for the quick response. I have worked with CFX for many years and there the insertion of monitorpoints or user interfaces is very comfortable and also possible without noticeable delay. Maybe that's why I am a bit spoiled. In fact I think that the variant using the UDF is the best option and of course I have set the expert parameter correctly according to the instructions, but I still get the error message.
I also have a webex with the ansys support today. If they can offer me a working solution I can announce it here!
Thanks again and many greetings
Mohinder

CFX/ Fluent
 

I suppose that's subjective. Fluent users find CFX interface rather clumsy. I use both, though more of Fluent. But I have never heard of user interfaces in CFX. Do you mean user surfaces? Or is it something new?

Good that you have a webex planned with Ansys today. I hope they resolve the issue. You can certainly post the status, including if you need help with the UDF.

Hello, vinerm,
excuse me I meant user surfaces of course! These are indeed solved very comfortably in CFX, because it is possible to save the data structured in this way.
Regards

Arrays and Groups
 

If the points are not arbitrarily distributed on planes, then you can still go for point arrays and groups. That will reduce the number of monitors as well as number of files. However, now the data will be listed by node number and their locations instead of, say, by point names. But this would make it manageable. The output will be similar to what you get from CFX, a comma or space separated file.

Do you actually want 100k distinct points? Why can't you just make several planes? I've never known of anyone to actually desire 100k distinct points, keep track of them, and do post-processing this way. Heck, back in 32-bit excel, there weren't even 100k lines for you to even write down all your points.

Vinerm,
I dont know the function of point arrays and lists? Can you explain how this is done in fluent?
Regards

Mohinder

Lucky Tran,
the reason is that I have 70million elements in my mesh and I need highly time resolved data output (3D) in the region of interest (near a turbine blade).

Ansys support told me to mark the cells near the blade via "mark/addapt cells -> boundary" and then split this reagion to enable a distinct 3D output in the near blade region!
I will try this and update you if this is working out for me!
Greets

Mohinder

Point Array and Cell Marking
 

If all the points are located in a specified region, then Marking the cells is a better idea. Point array would work for a cuboid region, not for a region shaped like a blade, which you most likely need. Earlier you mentioned that the points are on planes, that's why I mentioned point arrays. But if you want region around the blade(s), better mark those using Mark under Adapt. Then, separate those from the rest of the cell zone.

Point arrays are available under surface command.

The workaround with the marked cells worked quite well for me!

Nevertheless, im interested to get the UDF, working!


I managed to compile the udf and it is reading the coordinates from the input file, but then it crashes with an SIGSEGV error.



Now I want to debug the UDF using Messages, but unfortuantely no message/message0 are plotted in the out file! The messages are only plotted if the udf is in the #if RP_HOST mode. Is there a way to see the messages even if in #if !RP_HOST mode?

Sorry im not experienced in UDF.



Greets Mohinder

The UDF for the file-read of the monitor point coordinates is:

Debugging
 

Do you get segmentation violation just by running this part of the code? I did not see anything that should cause it but there could be potential bugs, could also be due to version difference. Anyway, Message0 implies Message only from node0. So, it will work within !RP_HOST but only when it is node0 that is doing the processing. However, Message works everywhere. Each node should give message. The messages are printed in any out file, rather within Fluent's text interface, where all the residuals are printed. Those will be in a file if you run Fluent in batch. If messages are not appearing, then most likely Fluent does reach that level, either because it is within certain logical condition and the condition is not met or it is in a loop and the loop does not run.

Hi vinerm,
thank you for your answer! The last Message i recieve in the out-file is


And even if I replace every Message0 with Message I dont get any further messages inside the out file =| even if I put it directly behind




That is so weird =|

My journal file for the testing is:

Message
 

That means it is not even going beyond #if !RP_HOST, which is weird. Did you try this in Serial?

Journal
 

I just saw your journal. What is the objective of executing the reading UDF again and again? Are there any changes in the input file? If not, read it just once.

Hi venerm,
of course you are right, this is not needed but it shouldnt affect the testing I think.

Thank you for the advice to try it in serial mode. I tried with the -t0 option but there are still some errors appearing allthough it doesnt crash

PS: Thank you very much for your help!

Error
 

The effect of reading again could cause error if Fluent tries to rewrite a memory while it should not be rewritten. So, instead of reading it using Execute-Command, read it within the journal by using the command just once. See if it still gives error. Once segmentation fault appears, Fluent usually gets stuck, however, that depends on whether the error flushes the cache or not. This one does not seem to be doing that, hence, Fluent runs despite the error.

Hi vinerm,
thanks for the advide, I changed it but its giving the same error. But at least now i get the break point messages so I will try to debug the udf further in order to find the point where it is giving the error! hopefully I will be able to get it working...



Thank you very much for your help!

Good
 

That's good. Let me know if you need further help.

Good morning vinerm,
thanks to your help, i was able to get the UDF working (at least in serial mode)! It is perfectly doing what it is supposed to be now and when I finnished the parallelization I will post the final solution here!
Now I am wondering if it is possible to also interpolate the q-criterion in these desired points! I've read some threads regarding custom field functions and user defined scalars, but i dont know what will be the most elegant solution as I not only need the values of Q in the cell centers, but also the derivatives for the final interpoaltion!
Do you have any suggestions how to approach this problem?

Thanks in advance!!


Mohinder

Q-Criterion
 

As far as defining a Custom Field Function is concerned, it is easy. You can refer the following

useful-les-tools-fluent

As far as UDF is concerned, though strain rate is directly available, vorticity is not. So, you have to use velocity gradients to define Q-criterion. You can fetch gradients or reconstruction gradients using C_DUDX(c, t), C_DUDY(c, t), etc. These can also be fetched using C_U_G(c, t)[0], where 0 implies x and so on.

You may have to issue the following command in your setup before the gradients become available because Fluent does not store those values.

solve set expert

And then Yes as a response to the question to keep the temporary memory from being freed. Then using these gradients, you can define q-criterion and write it to file.

Thank you for your reply!
I think that both ways only give me the values of q at the node centers, but I also need the gradients of q to finally interpolate the value at the desired monitor points. Is there a way to also get access to the gradients of q?


Greets

Mohinder

Q gradients
 

As such, q-criterion is not defined as a primitive variable in Fluent. Therefore, its gradients are not available as well. So, the only way is to determine its gradient from its definition (using a pencil and paper) and then make use of that equation to determine its gradients within UDF. Do note that all values starting with C_ are cell center based. To fetch values at nodes, you have to loop over nodes.

Yes, that would be a solution...
but I also found this example in the manual (example2)
Do you think that this would also be an option?

https://www.afs.enea.it/project/nept...udf/node20.htm

Uds
 

This will increase an equation in your case. Fluent solves full conservation equation for UDS. In my view, this would be an overkill just to fetch q-criterion at some points. Secondly, you have to ensure that despite UDS being solved, its values are determined on the basis of velocity gradients.

Im referring o this post:
https://www.cfd-online.com/Forums/fl...-function.html

Cff
 

There are no options (nor is there any requirement) to determine gradients of CFF. Gradients are available only for field variables. CFF is a field variable but an algebraic one. So, only those fields for which conservation equation is solved need their gradients because flux need to be determined at the faces for solving the equation.

Hello Mohinder,

Did you manage to use the code in parallel?
I want to extract Cp and V from more than 2000 points, which are defined in a separate file(as was in your case)
I used your udf to test it, I appreciated, however, when I try to use it in parallel cores (160 cores) it gives me an error, and it seems that udf needs parallelization.
I am a newbie in udf usage, any help is welcome.
Regards

Sergen

show your code and error log if you need help