Adrian
Forum Replies Created
-
Posts
-
Solution for what? Did you actually change the physical parameters or just the collision model?
I repeat: The error here is the difference between simulation and expected reference solution, not a program error. If you mean the gnuplot warning: just install gnuplot if you want to directly generate result plots for your simulation.
What do you mean by “required output”? Going by your first message I guess you just want to change the physical parameters which you can achieve by changing the parameters given to the unit converter.
This is not an error – the same message (with different results) is also printed for the unmodified lid driven cavity case. As the description suggests it is not a program error but the numerical error between simulation and reference solution.
The problem is that your custom field PREV_PHI is not a member of DESCRIPTOR but a separate type. Simply amend your field get/set functions to use it without the DESCRIPTOR:: prefix.
Yes, this is possible and
particles::creators::addResolvedArbitraryShape3Dis the correct function for this. (One restriction that I am aware of is that the particles currently must be concave if you want to use the contact model)Ok, this is indeed a bug in the code. You should be able to fix it by changing line 142 of
src/core/blockLattice.hhto:popF(pop, loc.data());or using
SuperLattice::defineField<POPULATION>Sorry about this and thanks for discovering this issue!
I also pushed a fix to the public branch.
What is the type of
populationPF?Coupling ADE to a free surface model for the fluid phase should be possible in the way you describe (there may be some modification required in the specific coupling operator you want to use). Of course transport within the gas phase won’t be covered by such a combined model by definition.
What do you mean by “the simulation didn’t run”? Which error / problem did you get? The example case on its own should be a good choice for a starting point in your case.
You can visualize streamlines in ParaView using the “Stream Tracer” filter on the velocity field produced by OpenLB. Similarly you should be able to compute the drag there (although OpenLB includes a drag/lift computation functor, this is used by e.g. the cylinder3d example case).
You can use the SuperF-accepting overload of
SuperLattice::definePopulationsinstead. If the discretization is identical (as it needs to be for coupling two lattices) you can directly pass yourpopulationAfunctor.Communicate-to-all communicates the results of all evaluations to all processes. e.g. this can be used if all processes need to iterate over the whole simulation domain (but not all processes hold all data, i.e. parallelization is used).
For Multi-Phase models external forces such as gravity are usually defined via the
descriptors::EXTERNAL_FORCEfield. You can check out e.g. the Rayleigh Taylor example case.You can access the physical location of each discrete lattice location using the
CuboidGeometry::getPhysRmethod. If you need this in the described matrix format you can generate it using this information by e.g. assigning a globally unique cell ID as a combination of global cuboid index and block-local cell ID (obtainable viaBlockStructure::getCellId).Ok, judging from the initial log you are compiling inside WSL?
Which distribution are you using and how / which MPI packages did you install?
Following the “tech report” you are likely missing the
libopenmpi-devpackage.Which MPI version are you using and can you share details on your system? The mpic++ wrapper should set the required include paths automatically (it is it’s main point). The issue is that does are not found in your environment.
Yes, this issue was caused by enabling the “communicate to all”-mode with the second constructor argument. Happy to hear that the default arguments worked for you.
In any case: Be aware that this functor will interpolate the values, this is not necessary when sharing the same discretization (as you do here due to constructing both lattices from the same super geometry).