home.social

#continuummechanics — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #continuummechanics, aggregated by home.social.

  1. The most accurate carotid artery model to date — the first to capture both the soft, low-pressure behavior and the stiff, high-pressure response of the vessel.

    Built on the same principles as Fung’s law, but improved: our 2014 α–β framework fits strain energy first, then derives pressure — like how \( F = \frac{dE}{dx} \) gives the force in a spring. Here \(E\) is the strain energy — the quantity Fung’s law was originally built around. Strain energy is differentiated to give force, and in the fits below that force corresponds to pressure.

    The 1987 plot below (Fung-type) fits well only at high pressures; the 2019 plot fits low pressures. Ours is the first to capture both perfectly.

    #Biomechanics #ContinuumMechanics #MathematicalModeling #StrainEnergy #FungsLaw #ConstitutiveModeling #Mechanics #NSFResearch #ScienceCommunication #ArterialMechanics

  2. Talking about dependencies: one thing we did *not* reimplement in #GPUSPH is rigid body motion. GPUSPH is intended to be code for #CFD, and while I do dream about making it a general-purpose code for #ContinuumMechanics, at the moment anything pertaining solids is “delegated”.

    When a (solid) object is added to a test case in GPUSPH, it can be classified as either a “moving” or a “floating” object. The main difference is that a “moving” object is assumed to have a prescribed motion, which effectively means the user has to also define how the object moves, while a “floating” object is assumed to move according to the standard equations of motion, with the forces and torques exerted on the body by the fluid provided by GPUSPH.

    For floating objects, we delegate the rigid body motion computation to the well-established simulation engine #ProjectChrono
    projectchrono.org/

    Chrono is a “soft dependency” of GPUSPH: you do not need it to build a generic test case, but you do need it if you want floating objects without having to write the entire rigid body solver yourself.

    1/n

    #SmoothedParticleHydrodynamics #SPH #ComputationalFluidDynamics

  3. Talking about dependencies: one thing we did *not* reimplement in #GPUSPH is rigid body motion. GPUSPH is intended to be code for #CFD, and while I do dream about making it a general-purpose code for #ContinuumMechanics, at the moment anything pertaining solids is “delegated”.

    When a (solid) object is added to a test case in GPUSPH, it can be classified as either a “moving” or a “floating” object. The main difference is that a “moving” object is assumed to have a prescribed motion, which effectively means the user has to also define how the object moves, while a “floating” object is assumed to move according to the standard equations of motion, with the forces and torques exerted on the body by the fluid provided by GPUSPH.

    For floating objects, we delegate the rigid body motion computation to the well-established simulation engine #ProjectChrono
    projectchrono.org/

    Chrono is a “soft dependency” of GPUSPH: you do not need it to build a generic test case, but you do need it if you want floating objects without having to write the entire rigid body solver yourself.

    1/n

    #SmoothedParticleHydrodynamics #SPH #ComputationalFluidDynamics

  4. Talking about dependencies: one thing we did *not* reimplement in #GPUSPH is rigid body motion. GPUSPH is intended to be code for #CFD, and while I do dream about making it a general-purpose code for #ContinuumMechanics, at the moment anything pertaining solids is “delegated”.

    When a (solid) object is added to a test case in GPUSPH, it can be classified as either a “moving” or a “floating” object. The main difference is that a “moving” object is assumed to have a prescribed motion, which effectively means the user has to also define how the object moves, while a “floating” object is assumed to move according to the standard equations of motion, with the forces and torques exerted on the body by the fluid provided by GPUSPH.

    For floating objects, we delegate the rigid body motion computation to the well-established simulation engine #ProjectChrono
    projectchrono.org/

    Chrono is a “soft dependency” of GPUSPH: you do not need it to build a generic test case, but you do need it if you want floating objects without having to write the entire rigid body solver yourself.

    1/n

    #SmoothedParticleHydrodynamics #SPH #ComputationalFluidDynamics

  5. Talking about dependencies: one thing we did *not* reimplement in #GPUSPH is rigid body motion. GPUSPH is intended to be code for #CFD, and while I do dream about making it a general-purpose code for #ContinuumMechanics, at the moment anything pertaining solids is “delegated”.

    When a (solid) object is added to a test case in GPUSPH, it can be classified as either a “moving” or a “floating” object. The main difference is that a “moving” object is assumed to have a prescribed motion, which effectively means the user has to also define how the object moves, while a “floating” object is assumed to move according to the standard equations of motion, with the forces and torques exerted on the body by the fluid provided by GPUSPH.

    For floating objects, we delegate the rigid body motion computation to the well-established simulation engine #ProjectChrono
    projectchrono.org/

    Chrono is a “soft dependency” of GPUSPH: you do not need it to build a generic test case, but you do need it if you want floating objects without having to write the entire rigid body solver yourself.

    1/n

    #SmoothedParticleHydrodynamics #SPH #ComputationalFluidDynamics

  6. Talking about dependencies: one thing we did *not* reimplement in #GPUSPH is rigid body motion. GPUSPH is intended to be code for #CFD, and while I do dream about making it a general-purpose code for #ContinuumMechanics, at the moment anything pertaining solids is “delegated”.

    When a (solid) object is added to a test case in GPUSPH, it can be classified as either a “moving” or a “floating” object. The main difference is that a “moving” object is assumed to have a prescribed motion, which effectively means the user has to also define how the object moves, while a “floating” object is assumed to move according to the standard equations of motion, with the forces and torques exerted on the body by the fluid provided by GPUSPH.

    For floating objects, we delegate the rigid body motion computation to the well-established simulation engine #ProjectChrono
    projectchrono.org/

    Chrono is a “soft dependency” of GPUSPH: you do not need it to build a generic test case, but you do need it if you want floating objects without having to write the entire rigid body solver yourself.

    1/n

    #SmoothedParticleHydrodynamics #SPH #ComputationalFluidDynamics

  7. With Pierre Recho, we're now giving a doctoral-level course on #continuumMechanics and #thermodynamics of #LivingMatter.

    That's the 2nd edition, the 1st one led us to write the ⬆️ above paper ⬆️ .

    Lecture notes are online, happy to have feedback!

    liphy-annuaire.univ-grenoble-a

  8. Dear fellow physics teachers (especially of continuum-mechanics-related disciplines): do you have any suggestions, thoughts, personal experiences, and references about nice *graphical representations* of the flux of a vector quantity – for instance momentum flux (in momentum transport)?

    Cheers!

    PS: what tags can be good & appropriate for a request like the present one?

    #physicseducation #physics #continuummechanics #fluidmechanics #AAPT