https://linen.dev logo
Join Discord
Powered by
# multiphase
  • b
    just to test out how it would behave honestly, i was thinking of using abaqus cause i kept on seeing linkedin posts where they brag about their "sticky" features so i was thinking sph particles and then define how they interact to somehow simulate the flocculation process
  • o
    okey, a small progress on this, the error was quiiiiite misleading. the issue is that in v13 org, introduced the source {} dictionary for the f* boundary/initial conditions files (the f* represents the distribution of sizes for the population balance) and now we need to put the fvmodels with a corresponding condition inside source. having my doubts in what i should enter in this dictionary, tested with Nan but it crashed the solver anyway.
  • o
    i finally succed in moving the simulation to v13. @tkeskita i am tagging you as i know that you use org version, personally I am having a speed up of around 45% for my simulation
  • y
    do you have an idea of the source of the speed up? (I mean is it related mostly to a specific change, or just the sum of many changes in the code?)
  • o
    LOL man you know me. i barelly got the case to be able to run without documentation XD. in any case i compared the results and the two give extremelly similar result with one and the other. this is multiphase, with species transfer, bubble size population, brekup and coallesence of bubbles and laminar flow.
  • y
    Just asking out of curiosity, as there are multiple changes related to multiphase and VOF in OF-13. I'm wondering if there could also be a speed up on the incompressibleVoF module
  • o
    but citing from the release notes:
    Copy code
    In the multiphaseEuler solver, the phase-pressure fluxes are cached from the previous iteration to avoid recalculation during sub-cycling and the correction loop and provide better consistency with the pressure equation in [ commit a8a84c78 ].  The solution algorithm for phase-fraction, developed for VoF solvers, has now been extended for the multiphaseEuler solver to provide faster solutions at high Courant numbers
    and also
    Copy code
    Mass transfer: Phase change processes in the multiphaseEuler solver have been rewritten
  • y
    alright, this would make sense
  • b
    Hi, Has anyone ever gotten the error below using the prghPermeableAlphaTotalPressure boundary condition when using the twoPhaseEulerFoam solver (OpenFOAM v2506)? Do you know how to get around it?!
    Copy code
    --> FOAM FATAL ERROR: (openfoam-2506)
updateCoeffs(const scalarField& snGradp) MUST be called before updateCoeffs() or evaluate() to set the boundary gradient.

    From virtual void Foam::prghPermeableAlphaTotalPressureFvPatchScalarField::updateCoeffs()
    in file fields/fvPatchFields/derived/prghPermeableAlphaTotalPressure/prghPermeableAlphaTotalPressureFvPatchScalarField.C at line 254.

FOAM exiting
  • z
    I think I might have run into a similar error before with fixedFluxPressure? From memory it had something to do with whether or not you'd specified 'value' in your BC
  • z
    there was an if statement in the BC that was triggered or not depending on if value was supplied
  • z
    and that caused issues
  • z
    But I could be remembering it wrong
  • b
    I think I can try testing without value then...
  • b
    Hi, I'm trying to run the OpenFOAM 9 bubbleColumn tutorial (multiphaseEulerFoam LES tutorial) with NicenoKEqn for the continuous phase and laminar for the dispersed phase, and apparently, it's not working correctly. The solver literally seems unable to handle it. It's curious that the author's (Niceno) approach in his article uses the dispersed phase as laminar. Of course, in the author's study, he considers the domain completely filled with water... however, the error, especially in the k.water solution, doesn't "seem to make sense." Would anyone be able to tell me why this happens?
  • k
    Does anyone have experience with using the irregularMultiDirectional model with waveModels for generating JONSWAP wave spectra? I have a python script to generate a basic JONSWAP spectra which seems to work fine for some coarse tutorial meshes, but the inlet on an actual case just has the surface dropping like this for some reason. https://cdn.discordapp.com/attachments/726377729229979669/1396904551134531745/image.png?ex=687fc83e&is=687e76be&hm=8ae1d00d631623c6d0ce696eb468b156c510566e345efacb0f1f94743bd395c1& https://cdn.discordapp.com/attachments/726377729229979669/1396904551617003712/generate_waveProperties.py?ex=687fc83e&is=687e76be&hm=eee69aa6b3d8099b22c753ef196ffdd32bc1e4c42cc6fb8849a0285403f7f016&
  • s
    Your Hs is big, 8 m!
  • s
    Wich is the depth of your mesh?
  • s
  • s
    Do you recognize that bad boy?
  • k
    oh I forgot to change the default settings of the script before I sent it over, I was testing it with a coarse mesh and just used 8m to get a clear visualization. My actual mesh has a water depth of 125ft, with the floating rigid body being 6ft (1.8288m) in height for reference. I use a Hs=6ft, Tp=6s JONSWAP with that mesh. I've been trying to test with 5m 5s stokesV waves instead as a simpler test just to confirm it doesnt do a nose dive at the beginning, and my iteration #s look fine in my log file but I keep getting division by zero or some floating pt error in GAMG. I do get warnings about quadAreaCoeffs and cutPoints in my log file as well, but I don't think my mesh is the problem as it's imported from a STARCCM sim that has good convergence as well, albeit with AMR enabled there (cant have AMR with rigid body mesh motion in openfoam). I know that the quadAreaCoeffs and cutPoints warnings generally indicate problems with the cells due to the mesh motion, however as this is only a few seconds in the waves haven't gotten close to the rigid body and there appears to be no deformation near the body (inner and outer distance in dynamicMeshDict are 4.0 and 30.0 respectively) I suspect it's likely due to the extreme wave heights of the stokesV. However since this stokesV wave didnt do a nose dive as my JONSWAP spectra it seems that with a lesser wave height that matches the mesh refinement region will likely do fine.
  • k
    I will try a stokesV 1.8288m 6s wave to see if my mesh encounters any problems just to confirm, but I think that my mesh and inlet does fine for other wave conditions in general as I do not find a massive drop of the water surface at the inlet. I do not have much experience with wave spectra, and am only using a a JONSWAP wave in the +y direction with no directional diffusion as I am validating a physical model flume test. I have several runs with the same spectra in STARCCM and the JONSWAP seems to do fine with no directional diffusion there. Given the stokesV waves seem to work fine and only encounter problems from the wave height being outside the intended refinement region for the waves, I think there must be something wrong with my irregularMultiDirectional JONSWAP setup thats causing the water at the inlet to do such a massive drop
  • k
  • s
    Suggestion: Dont run with AMR just yet
  • s
    Second suggestion: use MKS for all communications. Nothing against feet and inches, but reading your script I dont understand what units are you referring to. I see also a lot of 6's so I dont know whether is a typo
  • s
    "Directional Diffusion"? You mean "Spreading"?
  • k
    Yes I mean spreading I just didn't know the proper term
  • s
    It definetely looks like paddle driven waves
  • k
    I am still getting the water surface drop at the inlet (here it's approximately 12m from the starting water surface level) even with a StokesV wave of 1.8288m and 6s period. I thought that nPaddles=1 is fine for when I'm only going for waves with no spread like I see in many tutorial cases, but could nPaddle being too low be the problem? I'm not sure what could be causing this extreme drop https://cdn.discordapp.com/attachments/726377729229979669/1398295004228878497/image.png?ex=6884d734&is=688385b4&hm=a33cc67a1c8286d54a7f726c13808a06995332626d0833c9c2bc7921a3878a15& https://cdn.discordapp.com/attachments/726377729229979669/1398295004564426792/image.png?ex=6884d734&is=688385b4&hm=be7d0f610fc7bac9fae3b6d8bb022742fa15849e753b15c0ae25b455bc5dbcc4&
  • k