Extensions to WaterLily all broke when going to 1.4/1.5

[weymouth]

The BiotSavartBC extension to WL can't be used with v1.4 or 1.5. This is because the BC types and internals to mom_step! were are changed.

This was marked as a breaking change, so it's ok in principle. But if we anticipate that we will have more extensions to WL capabilities in the future (Multi-Phase flow, Fluid Structure Interactions, etc) then we should consider design improvements to WL that could help avoid breaking things downstream.

For now, I notice that mom_step! lives in Flow.jl, but it depends on almost everything in Simulation. Moving it to WaterLily.jl and giving the full Simulation as an input would allow people to type-specialize. We could also try to refactor it a bit since it's repetitive and a little arbitrary. For example, we need BC! enforcement inside the project function for BiotSavartBCs (since they are applied iteratively). I'm not sure if a similar issue arises in MultiPhase flows (@TzuYaoHuang) or FSI (@marinlauber).

[TzuYaoHuang]

I’ve encountered some issues following recent changes to save!, load!, BCTuple, flow.U -> flow.uBC, and BC!. While I certainly prefer a bit more stability, I understand that WL is still evolving quickly. Once the package becomes more mature -- or as more developers involving in building extensions or codes based on WL -- I think it would be helpful to keep older functions around temporarily with deprecation warnings and reduce renaming unless it’s really necessary. That would help ease the maintenance burden for downstream users.

Regarding mom_step!, I completely agree with the idea of changing the input to accept the full Simulation object. One additional advantage is that we can put some shared object inside Simulation, where I see perdir as one possibility. As for duplication, there isn’t much concern on my end, since my numerical approach is quite specialized and diverges significantly from the single-phase method.

[marinlauber]

I think I might have the opposite view, I think 'mom_step!' should remain a momentum step. Some 'sim_step!' might involve more than a momentum step, for example in 'CoupledSimulation' this actually involves solving the fixed point problem, which calls 'mom_step!' and a lot of other functions.

This allows different 'AbstractSimulation' to call the same momentum step, plus specialised methods.

[weymouth]

Maybe we should think about this in terms of what really needs to be adjusted for these various extensions. A CoupledSimulation can use any Flow, Poisson, or Body, right? It just adds an additional coupling equation and a loop, so a new simulation object makes the most sense.

A VOF simulation adds new Flow variables and has a unique mom_step!. But it might be able to reuse MultiLevelPoisson and the same projection methods and it doesn't really change anything at the simulation level. Maybe this should be a new VOFFlow struct.

The BiotSavart BCs obviously modify the boundary conditions, and they also need to change project. I'm still in favour of moving the velocity BC enforcement into the project function since they are tightly coupled. But once that is done the BiotSimulation function could just return a regular Simulation which has a new BiotPoisson struct inside it.

Would this approach let us use a CoupledSimulation with the BiotSavart BCs and a turbulence model??

[marinlauber]

Yes I think this is what makes most sense. CoupedSimulation can have either a classical or a BiotSavart simulation, that doesn't make a difference.

[b-fg]

I am working on this... I have a WIP that adds BC! within project!, and this function dispatches to a new BC type, which inherits from AbstractBC. Users can define their own BCs, and these will be called in project!

[marinlauber]

Actually, I really like this idea! Maybe we should think of a way to separate all the 'BC!' calls from the main solver, to enable multi-CPU/GPU computation using for example 'ImplicitGlobalGrid.jl', just by calling a 'BC!' function that does the MPI communications.

[weymouth]

That's how Lotus worked with mpi! Let's do it! Gabriel D Weymouth

…

_______________________________________________ "Computers are useless. They can only give you answers." Pablo Picasso

On Thu, Jul 3, 2025, 20:04 Marin Lauber ***@***.***> wrote: *marinlauber* left a comment (WaterLily-jl/WaterLily.jl#228) <#228 (comment)> Actually, I really like this idea! Maybe we should think of a way to separate all the 'BC!' calls from the main solver, to enable multi-CPU/GPU computation using for example 'ImplicitGlobalGrid.jl', just by calling a 'BC!' function that does the MPI communications. — Reply to this email directly, view it on GitHub <#228 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADSKJ6LI7TKU6NG76SBP2L3GVWB5AVCNFSM6AAAAAB7BZ4PIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMZTGEYTKOJWGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[b-fg]

I'm very close to a first working version, but there's a bug messing around