[jan]

Dear Rookie,

Henn has used this code extensively, so I suggest you check out his dissertation (DOI: 10.5445/IR/1000061601).

For more in-depth discussions, you should consider attending the next occurrence of our annual [Spring School](https://www.openlb.net/spring-school-2024/).

Best regards,
Jan

[jan]

Dear Rookie,

I may have misunderstood you, but I suggest that you still read the files “one by one”. However, you can use a simple loop in c++ to do this for you by getting a list of files with the c++ function mentioned above.

But I want to emphasize that this is just a guess that it will work in your case, because I don’t have enough knowledge about your problem/case.

For more in-depth discussions, you should consider attending the next occurrence of our annual [Spring School](https://www.openlb.net/spring-school-2024/).

Best regards,
Jan

[jan]

Dear Rookie,

unfortunately, I’m not aware of what exactly you want to achieve and which functions you are currently using, but I’m glad to hear that you found a way to make it work. Though I don’t understand the issue with loading them separately as you could just use c++ features to iterate over all existing vtu files as mentioned here: https://stackoverflow.com/questions/612097/how-can-i-get-the-list-of-files-in-a-directory-using-c-or-c

Best regards,
Jan

[jan]

Dear Rookie,

I meant this part:

_minPhys(sg.getStatistics().getMinPhysR(2)),
_maxPhys(sg.getStatistics().getMaxPhysR(2)),

I haven’t checked the actual implementation, but usually this is used to evaluate where the fluid starts and ends, so that a particle leaving the fluid can be placed on the other side. However, usually 2 is for a wall, so this wouldn’t return the start and end of the fluid, but of the wall. This could (but doesn’t have to) cause your particles to behave wrong or “strangely” when they cross the periodic boundary.

Best regards,
Jan

[jan]

Dear Rookie,

removing the const keyword shouldn’t have any impact as long as you don’t try to manipulate the values that are stored in it.

Could you please clarify what you replaced with int overlap = 2; and why?

The overlap defines the size of the area in which the communication of data happens. For communication, the blocks must so that storage for the necessary neighborhood data is provided and accessible. Usually an overlap of 2 is sufficient.

Best regards,
Jan

[jan]

Dear Rookie,

I just wanted to quickly inform you of a possible problem:
The hardcoded material number in the code you provided is 2. Usually 2 corresponds to a wall, but in my opinion the periodic boundary should consider the fluid, which usually has the material number 1.

However, I don’t know your case, so this is just a guess and depending on your setup, both material numbers (1 and 2) could work and possibly give the same results.

Best regards,
Jan

[jan]

Dear Rookie,

what does the error say exactly?

I assume that the UnitConverter is declared constant in your app. However, the drag model expects a reference to a non-constant UnitConverter: SchillerNaumannDragModel(UnitConverter<T, Lattice>& converter);. The constructor of LaddForwardCouplingModel has the same problem. You could try to replace UnitConverter<T, Lattice>& converter with UnitConverter<T, Lattice> const& converter in the corresponding constructors or remove the const keyword from the line where you create the UnitConverter object.

Best regards,
Jan

[jan]

Dear Rookie,

I saw that you already found a way in the legacy code to couple back from the particles to the fluid: https://www.openlb.net/forum/topic/simulatewithtwowaycoupling/
I’m leaving it here in case someone in future stumbles over this thread.

Best regards,
Jan

[jan]

Dear Rookie,

Since this is old legacy code, my knowledge of it is limited, but I’ll try to help.

The posted source code shows that they’re mostly the same, but the _Davide code adds a few more functions at the end. The code deletes inactive particles, communicates the back coupling, and also updates the particle distributions twice. Why this is, I do not know. It could be that eraseInactiveParticles is also called here to avoid a second loop over all particles. Also, the _Davide code somehow doesn’t include an option to reset the back coupling forces.

For now, I’d suggest you try them both and see if you see any differences in the results. Do they both do the same thing in your application? Then it’s probably more efficient to use the first one. If the results are different, then you may need the second, as this could indicate missing communications.

The parameters and your explanations seem correct. If you don’t want the reset, then yes, you should set resetExternalField to false.

Best regards,
Jan

[jan]

Dear Rookie,

why do you need to move the ParticleManager to the old system? It’s mostly only for convenience, therefore, you don’t have to port the whole object. If you merely want to achieve the periodic boundaries, then it might suffice to merely check once per timestep if a particle left the periodic domain and if they did, place them on the opposite side of the periodic boundary.

Best regards,
Jan

[jan]

Dear Rookie,

Unfortunately, the new particle system does not include all features that are available in the legacy subgrid particle system. For that reason, the legacy particle system is included in the latest release as well (see src/particles/subgrid3DLegacyFramework, which you can use in the same way as you used it in 1.5.

The second part of the post I unfortunately don’t understand fully, because in both versions I’m not aware of any coupling from the subgrid particles to the lattice, only a coupling from the lattice (fluid) to the particles is used in the example, which uses the default Stokes drag as it does in version 1.5.

Best regards,
Jan

[jan]

Dear Rookie,

Sorry, I missed the second part of your question.

Unfortunately, there is no implemented method that allows for particle-wall interactions when considering subgrid particles using the new particle system. However, the legacy subgrid particle system is still available and can still be used. Alternatively, you’re free to port the functionality to the new particle system. However, I assume this is no small feat.

Best regards,
Jan

[jan]

Dear Jijo,

the DKT case is a very dynamic case and minimal changes can cause a huge deviation, as has been seen in the literature several times. For example, Koblitz et al [1] pointed out that a different contact model caused the difference to the results of Uhlmann [2].

As far as I know, there was no contact model in 1.5, which could lead to an incorrect representation. One has been added in 1.6, but differences in the model, particle properties, use of a ε boundary, and other differences from the literature could lead to different results.

In conclusion, it is likely that the results don’t exactly match other results in the literature, since the contact model has not been used before.

Best regards,
Jan

[1]: Koblitz, Arndt Ryo, et al. “Direct numerical simulation of particulate flows with an overset grid method.” Journal of computational physics 343 (2017): 414-431.
[2]: Uhlmann, Markus. “An immersed boundary method with direct forcing for the simulation of particulate flows.” Journal of computational physics 209.2 (2005): 448-476.

[jan]

Dear Rookie,

Unfortunately I’m traveling at the moment and can’t check the code sufficiently. However, the beauty of the new particle system is that we now have one particle system for subgrid and resolved particles.

So I suggest you check how gravity is added in examples/particles/dkt2d and you should be able to set it up similarly in your application. There you should find another task called apply_gravity and that the external acceleration is passed to the constructor of the ParticleManager. Therefore all particles must have the same density. If you need different densities, you’ll have to implement another function following the example provided.

Best regards,
Jan

[jan]

Dear Aditya Shukla,

Please provide some more details about the case you’re considering. For example, a (rough) sketch of the setup would help us understand it. Also, please highlight the question/problem you need help with. Is it a bug report or do you need help with OpenLB? What do you expect from the simulation (with reasons) and what do you actually get? Again, exporting and uploading the actual results you get would be helpful to understand your question.

For now, I can only suggest that you make sure that the materials are set correctly after applying your changes. You can do this by opening “tmp/vtkData/geometry_iT0000000.vtm” in ParaView. Does it look like the setup you had in mind?

Best regards,
Jan

[Author]

Posts