How to add tracers to fluid

[Hong Nguyen]

Hi All,

I like to add tracers to the fluid domain. These tracers only move with the local fluid flow, and of course they will not have any effect on the system's dynamics. To be more specific, tracers don't apply force to the fluid, but they interpolate velocity from the fluid (note that anchor point can only do the former, not the latter).

I was wondering if there is a way to do that in IBAMR?

Thank you,

Hong

[Hong Nguyen]

Continued with my previous message. I think regular vertex points can be used as tracer point as long as there is no spring connecting them. However, we need to create an IBMethod object to handle vertex points. I was wondering if there is a simpler way to include tracers, it is best if that can be done via input file.

Thanks,

Hong

[Amneet Bhalla]

One way could be to have an IBStrategySet with two IB methods. One IBMethod does all the work and the other is only advecting a tracer structure with the local fluid velocity. For the second IBMethod you can override its force spreading function to do nothing. 

Here is one example that I'd put together to combine 2 IBMethods in an app. 

https://github.com/IBAMR/IBAMR/blob/amneetb/revive-mls/examples/moving_least_squares/ex2/example.cpp#L196-L202

--
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/9ee0247e-958a-499d-aa15-d0187ac5d842n%40googlegroups.com.

--

--Amneet 

[Hong Nguyen]

Thanks, Amneet, I got your point. One thing still concerns me is that if tracer points are managed by an IBMethod object, then their movement will trigger (unnecessary) regridding and inter-processor communication more frequently for high enough tracer density, thus reduce the computational efficiency.

Anyway,  I guess IBStrategySet is the only option we have now.

Thanks,

Hong   

[Boyce Griffith]

On Apr 16, 2021, at 8:57 AM, Hong Nguyen <hon...@gmail.com> wrote:

Thanks, Amneet, I got your point. One thing still concerns me is that if tracer points are managed by an IBMethod object, then their movement will trigger (unnecessary) regridding and inter-processor communication more frequently for high enough tracer density, thus reduce the computational efficiency.

Anyway,  I guess IBStrategySet is the only option we have now.

If this is for an AMR computation, then it is true that marker points generated in this way will induce different refinement patterns than for a case without them. Otherwise, there should not be much difference in the regridding, which is probably triggered by flow conditions and not by the movement of the structure.

The main optimization that could be done is to skip force spreading for the marker points. That would come into play if the number of marker points is much larger than the number of structural points. Does that happen for your intended use case?

— Boyce

To view this discussion on the web visit https://groups.google.com/d/msgid/ibamr-users/502d274a-2b3d-40eb-8d22-fba64f78ac8dn%40googlegroups.com.

[Hong Nguyen]

If this is for an AMR computation, then it is true that marker points generated in this way will induce different refinement patterns than for a case without them. Otherwise, there should not be much difference in the regridding, which is probably triggered by flow conditions and not by the movement of the structure.

Please correct me if I am wrong, I thought that if a tracer point happens to be at a high fluid velocity region at some time, then it could result in an unnecessary regridding because the tracer would have moved more than the CFL fraction of meshwidths, while this would not occur if there is no tracer. So, the presence of tracer will change the regridding frequency. am I missing something?

Thanks,

Hong

[Amneet Bhalla]

It may. The best thing would be to try it out. My guess is that it won’t be that bad.

In any case, you would need to maintain the CFL condition of marker points in parallel and AMR to avoid “loosing” them. That is independent of the fact that marker points are coming from an IBMethod. 

--

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/014cb233-cdf9-4d0d-8082-fba80bb73b77n%40googlegroups.com.

--

--Amneet 

[Boyce Griffith]

On Apr 16, 2021, at 10:41 AM, Amneet Bhalla <mail2...@gmail.com> wrote:

It may. The best thing would be to try it out. My guess is that it won’t be that bad.

It won’t — see below.

In any case, you would need to maintain the CFL condition of marker points in parallel and AMR to avoid “loosing” them. That is independent of the fact that marker points are coming from an IBMethod. 

On Fri, Apr 16, 2021 at 7:25 AM Hong Nguyen <hon...@gmail.com> wrote:

If this is for an AMR computation, then it is true that marker points generated in this way will induce different refinement patterns than for a case without them. Otherwise, there should not be much difference in the regridding, which is probably triggered by flow conditions and not by the movement of the structure.

Please correct me if I am wrong, I thought that if a tracer point happens to be at a high fluid velocity region at some time, then it could result in an unnecessary regridding because the tracer would have moved more than the CFL fraction of meshwidths, while this would not occur if there is no tracer. So, the presence of tracer will change the regridding frequency. am I missing something?

This can only happen if the presence of the marker points actually changes the flow — which can only happen if you are using AMR and if the marker points are in part of the domain that would not otherwise be refined, so that there is additional regions of refinement beyond what would happen without markers. If you are not using AMR, or if the markers are restricted to a part of the domain that is already highly refined, then adding markers will not change the regridding frequency.

The basic criterion that is used to determine when to regrid the computational domain is based on the maximum flow velocity in the domain and is independent of the structure motion. There is a non-dimensional parameter called the “regrid CFL interval” — let’s call it C_regrid — that controls the regridding frequency.

The idea is that we can bound the distance that any particle can possibly move during a time step using the maximum flow velocity and the time step size.

(max displacement) <= (maximum velocity) * dt

It is actually more convenient to use a non dimensional displacement that is expressed as a fraction of the Cartesian grid spacing:

(max non dimensional displacement) <= (maximum velocity) * dt / h

Notice that the right-hand side is just the CFL number of the flow.

The default implementation just adds up the CFL number in each time step since the most recent regridding operation — which is the maximum number of fractional mesh widths that any particle could move since that regridding operation — and, once that sum exceeds C_regrid, regridding is triggered. In the examples, we usually set C_regrid = 0.5, which means that regridding is triggered once any material point could have possibly moved half a mesh width. Again, notice that this criterion does not depend on the actual motion of the structure, just the flow velocity magnitude on the Cartesian grid.

By the way, this is the same kind of criterion that you would want to use to ensure that flow features are captured by the AMR grid — if a flow feature can move too far between regridding operations, then it can escape its targeted level of spatial resolution.

This is probably overly conservative for structural motion, and, in fact, IBFEMethod actually has a second option that is based on the actual displacement since the most recent regridding operation. I don’t think this true displacement-based criterion is currently implemented for any other IB method implementation.

Of course, if you are using AMR, it may be reasonable to want the markers to be assigned to the finest available level of the AMR grid at their current location. (I.e., to avoid having the markers themselves induce local mesh refinement.) I set up LMarker and LMarkerUtilities to facilitate this kind of stuff a long time ago, but I don’t know how recently it has been used. Perhaps you could try it out . . . I think all you need to do is to specify a marker file name in the IBHierarchyIntegrator input database:

IBHierarchyIntegrator {

   /// … other settings …

   marker_file_name = “markers.vertex”

}

— Boyce

Thanks,

Hong

--

--Amneet

[Boyce Griffith]

On Apr 16, 2021, at 11:54 AM, Boyce Griffith <boy...@gmail.com> wrote:

On Apr 16, 2021, at 10:41 AM, Amneet Bhalla <mail2...@gmail.com> wrote:

It may. The best thing would be to try it out. My guess is that it won’t be that bad.

It won’t — see below.

In any case, you would need to maintain the CFL condition of marker points in parallel and AMR to avoid “loosing” them. That is independent of the fact that marker points are coming from an IBMethod. 

On Fri, Apr 16, 2021 at 7:25 AM Hong Nguyen <hon...@gmail.com> wrote:

If this is for an AMR computation, then it is true that marker points generated in this way will induce different refinement patterns than for a case without them. Otherwise, there should not be much difference in the regridding, which is probably triggered by flow conditions and not by the movement of the structure.

Please correct me if I am wrong, I thought that if a tracer point happens to be at a high fluid velocity region at some time, then it could result in an unnecessary regridding because the tracer would have moved more than the CFL fraction of meshwidths, while this would not occur if there is no tracer. So, the presence of tracer will change the regridding frequency. am I missing something?

This can only happen if the presence of the marker points actually changes the flow — which can only happen if you are using AMR and if the marker points are in part of the domain that would not otherwise be refined, so that there is additional regions of refinement beyond what would happen without markers. If you are not using AMR, or if the markers are restricted to a part of the domain that is already highly refined, then adding markers will not change the regridding frequency.

Also, I was not clear enough here — although changes in local mesh refinement can cause changes in the flow (and hence in the regridding frequency), those changes should be small.

The major impact on runtime would be if the markers induce local mesh refinement that results in a much larger fine grid — that is the problem that the LMarker data structures are meant to address.

— Boyce

[Hong Nguyen]

Thanks, Boyce and Amnnet, very useful information.

It is very surprising that the use of LMarker and LMarkerUtilities has not been demonstrated in any examples. From what just described, I believe they are very helpful for me (and hopefully for other users).

Thanks,

Hong

[Amneet Bhalla]

We would welcome an example in the library!

--

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/af16c045-ff5f-4031-86a1-bea5b60145aan%40googlegroups.com.

--

--Amneet 

[Sagar G Nayak]

I am trying to put a tracer in my fluid field (in ConstraintIB) and found this thread.

This method looks bit difficult to me. Can't we just define and register a scalar field using functions like "registerTransportedQuantity" as used here?

https://github.com/IBAMR/IBAMR/blob/e257bd3c8f991038b3ef3dfe0c755d176e3e677b/examples/advect/example.cpp#L176C24-L176C51

we can give advection velocity as "navier_stokes_integrator->getVelocityVariable()" in 

https://github.com/IBAMR/IBAMR/blob/e257bd3c8f991038b3ef3dfe0c755d176e3e677b/examples/advect/example.cpp#L177

I tried something on the similar line but my scalar is not evolving since "time_integrator" doesn't know about it. I can see my scalar in the VisIt window though.

If we could write these functions (registerTransportedQuantity, setAdvectionVelocity, setConvectiveDifferencingType etc.) in IBHierarchyIntegrator.cpp, it would be helpful it seems.

[Boyce Griffith]

We actually have been working on improving support for markers / tracers quite recently.

David / Marshall, can we use markers with any IB implementation or just with certain ones?

To view this discussion visit https://groups.google.com/d/msgid/ibamr-users/72a3cc86-51dd-484f-b7fd-ae91a4b3c470n%40googlegroups.com.

[Boyce Griffith]

Great!

Do we have any examples (or tests) that show how to set these up?

On Sep 6, 2025, at 10:15 AM, Davey, Marshall <mrd...@live.unc.edu> wrote:

The constraint is that it is only implemented through the IBExplicitHierarchyIntegrator time integrator currently (and any derived classes if there are any).

---

From: Boyce Griffith <boy...@gmail.com>
Sent: Saturday, September 6, 2025 10:09:32 AM
To: IBAMR Users <ibamr...@googlegroups.com>
Subject: Re: [ibamr-users] How to add tracers to fluid

 

[Boyce Griffith]

Great, thanks!

Sagar, let us know if this works for you and/or if you have questions or problems.

On Sep 6, 2025, at 10:35 AM, Davey, Marshall <mrd...@live.unc.edu> wrote:

Here are a test and an example with implementations (they are essentially the same). Note the extra parameters in the IBHierarchyIntegrator Database in the respective input files.

https://github.com/IBAMR/IBAMR/blob/master/examples/IBFE/explicit/ex4/example.cpp

https://github.com/IBAMR/IBAMR/blob/6e6c7a46bbccbee51bdb46daf67761076cc5cb2a/examples/IBFE/explicit/ex4/input2d.markers#L103

https://github.com/IBAMR/IBAMR/blob/master/tests/IBFE/explicit_ex4.cpp

---

From: Boyce Griffith <boy...@gmail.com>
Sent: Saturday, September 6, 2025 10:26:02 AM