Setting Vorticity Threshold

[Ezat Shokrani]

Dear IBAMR developers,

I have some questions about AMR method in IBAMR. I know that the AMR method in IBAMR (SAMRAI) refines meshes around the solid boundaries and also the somewhere in which the vorticity threshold becomes more than a predefined amount.

However, I have seen one of the posts (https://groups.google.com/g/ibamr-users/c/LRlipbmO1ZQ) that

Professor Bhalla has suggested this: “turning off vorticity tagging first, and then select a reasonable value based on visualizing the vorticity field.”. I have encountered some questions based on this suggestion.

1)When I turn off the “VORTICITY_TAGGING” while I have not done any mesh study, How I should be sure that my initial mesh size is suitable for the fact that the results are reliable for computing vorticity field?

2)What is “Reasonable Value” and how I should choose this for my case?

3)I have seen the input2d for “eel2d” case when you have chosen a four-level mesh patch size. Based on the fact that the “REF_RATIO“ is 4, you have adjusted the vorticity in each level to be gradually halved (“vorticity_abs_thresh”) for each level. Is it a rule of thumb which I have to follow for my case and does this related to the “REF_RATIO”?

4)I have seen when I use the IBAMR along with AMR method, the vorticities are solved behind the bluff body for a long distance and remain inside the solution domain. Is it possible to cut off capturing the vorticities after a definite distance behind the bluff body (without changing the amount of “VORTICITY_TAGGING”).

5) Is it possible to turn off the “VORTICITY_TAGGING” and instead, I use the” REFINE_BOXES” method with different groups and same number of levels but spatially and completely separate from each other in different places inside the domain?

 

I would appreciate your consideration for answering my questions.

 

Best regards,

Ezat Shokrani,

[Ezat Shokrani]

This is a reminder for the previous email that I sent.

[Boyce Griffith]

On Apr 13, 2021, at 12:16 AM, Ezat Shokrani <shokr...@gmail.com> wrote:

I have some questions about AMR method in IBAMR. I know that the AMR method in IBAMR (SAMRAI) refines meshes around the solid boundaries and also the somewhere in which the vorticity threshold becomes more than a predefined amount.

However, I have seen one of the posts (https://groups.google.com/g/ibamr-users/c/LRlipbmO1ZQ) that Professor Bhalla has suggested this: “turning off vorticity tagging first, and then select a reasonable value based on visualizing the vorticity field.”. I have encountered some questions based on this suggestion.

1)When I turn off the “VORTICITY_TAGGING” while I have not done any mesh study, How I should be sure that my initial mesh size is suitable for the fact that the results are reliable for computing vorticity field?

Vorticity tagging is a feature detection criterion that is used to determine where higher resolution is deployed in the flow field. It is possible to drive mesh refinement using either an absolute tolerance (i.e., a coarse grid cell is marked for refinement if the magnitude of the vorticity in the cell exceeds a given fixed value), or using a relative tolerance (i.e., a cell is marked for refinement if the magnitude of the vorticity exceeds some fraction of the current maximum vorticity magnitude).

Currently there are no other feature detection criteria in the library, although it should not be hard to add them.

In an FSI model, you also will typically assign the structure to a particular level of the AMR grid. The locally refined grid is generated in a way that ensures that the structure is covered by grid cells on its assigned level. In practice, we almost always assign structures to the finest level of the AMR grid. In these cases, vorticity tagging is primarily useful for capturing flow features that are shed off of the immersed structures. Whether you need to capture these flow features to resolve the FSI dynamics depends on the application.

2)What is “Reasonable Value” and how I should choose this for my case?

I don’t know how to answer this in the abstract. In general, you will want to increase the amount of resolution you are using until you achieve the accuracy needed by your application.

3)I have seen the input2d for “eel2d” case when you have chosen a four-level mesh patch size. Based on the fact that the “REF_RATIO“ is 4, you have adjusted the vorticity in each level to be gradually halved (“vorticity_abs_thresh”) for each level. Is it a rule of thumb which I have to follow for my case and does this related to the “REF_RATIO”?

The absolute tolerances are physical values of vorticity. In general, you will need to know something about your flow field to make reasonable choices.

The relative tolerances are just fractions of the current maximum vorticity. They are more useful for models where you don’t know much about the flow features.

Generally, I like to taper off the threshold, so that regions of high vorticity magnitude are slowly coarsened as the vorticity diffuses. If you use the same threshold for all levels, then vortices will be abruptly cut off as soon as they drop below the threshold.

4)I have seen when I use the IBAMR along with AMR method, the vorticities are solved behind the bluff body for a long distance and remain inside the solution domain. Is it possible to cut off capturing the vorticities after a definite distance behind the bluff body (without changing the amount of “VORTICITY_TAGGING”).

Not currently. However, you may be able to achieve what you want by altering the thresholds.

5) Is it possible to turn off the “VORTICITY_TAGGING” and instead, I use the” REFINE_BOXES” method with different groups and same number of levels but spatially and completely separate from each other in different places inside the domain?

I’m not sure that I understand your question, but with refine boxes, you just list a collection of boxes on each level that are to be refined, and the grid generation algorithm will simply refine them. There is no requirement that the boxes are connected or not. However, the boxes do need to be nested (the locations marked for refinement on finer levels need to be contained in the locations marked for refinement on coarser levels).

I think that SAMRAI supports prescribing a time-dependent refinement pattern, but I have never used it.

— Boyce

[Ezat Shokrani]

Dear Professor Griffith,

 

Thanks for your response. I know that the vorticity threshold depends on the application but, I do not know how I should set it for a specific case. For example, Professor Bhalla has validated the results of “eel2d” case in his article with the results reported in article entitled as ” Simulations of optimized anguilliform swimming”. For this case, the vorticity threshold has been set to be 2 (“vorticity_abs_thresh”) for the finest level (Level_3) in the article. I know that, for a case, the vorticity threshold should be a tradeoff between accuracy and performance, but Why did not he choose the amount 4 or 1 rather than 2? how I should be sure that the required accuracy is obtained by setting this amount?

In fact, I am going to validate the results of an experimental case (the PIV method has been used) in an article. I have seen, for the case of the article, the vorticities have been reported within the range of -4 and 4. Do you think that this amount is a “reasonable value” that I should use for setting the “vorticity_abs_thresh” in order to tag the vorticities?

 

I would be wondering if you could guide me on this issue.

 

Best regards,

Ezat Shokrani

[Amneet Bhalla]

Hi Ezat,

The best way is to try it out. Run some cases with low spatial resolution to get a quick idea on the vorticity range in your case, and then take it from there. That has been my approach for eel cases.

Thanks,

—Amneet

--
You received this message because you are subscribed to the Google Groups "IBAMR Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ibamr-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/83dbd1a0-7b12-4b7c-a276-f634914c4715n%40googlegroups.com.

--

--Amneet