Giter Site home page Giter Site logo

particulateflow / cfdemcoupling-pfm Goto Github PK

View Code? Open in Web Editor NEW
71.0 20.0 40.0 77.3 MB

This is an academic adaptation of the CFDEMcoupling software package, released by the Department of Particulate Flow Modelling at Johannes Kepler University in Linz, Austria http://www.jku.at/pfm

License: GNU General Public License v3.0

C 6.21% C++ 92.27% Shell 1.07% Python 0.14% MATLAB 0.23% TeX 0.01% Gnuplot 0.01% DM 0.01% Perl 0.04% M4 0.03%

cfdemcoupling-pfm's Introduction

CFDEMcoupling

CFDEM®coupling stands for Computational Fluid Dynamics (CFD) - Discrete Element Method (DEM) coupling. It combines the open source packages OpenFOAM® (CFD) and LIGGGHTS® (DEM) to simulate particle-laden flows. CFDEM®coupling is part of the CFDEM®project.

CircleCI License: GPL v3

Disclaimer

This is an academic adaptation of the CFDEM®coupling software package, released by the Department of Particulate Flow Modelling at Johannes Kepler University in Linz, Austria. LIGGGHTS® and CFDEM® are registered trademarks, and this offering is not approved or endorsed by DCS Computing GmbH, the official producer of the LIGGGHTS® and CFDEM®coupling software. This offering is not approved or endorsed by OpenCFD Limited, producer and distributor of the OpenFOAM software via www.openfoam.com, and owner of the OPENFOAM® and OpenCFD® trade marks.

Features

  • Documentation and tutorials to get started
  • A modular approach that allows for easy implementation of new models
  • MPI parallelization for large scale problems

License

License: GPL v3

  • This software is distributed under the GNU General Public License.
  • Copyright © 2009- JKU Linz
  • Copyright © 2012-2015 DCS Computing GmbH, Linz
  • Some parts of CFDEM®coupling are based on OpenFOAM® and Copyright on these parts is held by the OpenFOAM® Foundation (www.openfoam.org) and potentially other parties.
  • Some parts of CFDEM®coupling are contributed by other parties, which are holding the Copyright. This is listed in each file of the distribution.

cfdemcoupling-pfm's People

Contributors

aaigner avatar achuth1992 avatar asanaz avatar behradesg avatar cgoniva avatar danielque avatar ekinaci avatar markoramius avatar mathiasvangoe avatar pkieck avatar rbberger avatar tlichtenegger avatar tmjnijssen avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cfdemcoupling-pfm's Issues

Coarse-graining bug in HeatTransferGunn and HeatTransferRanzMarshall

coarse-graining factors not overwritten if the CoarseGrainingFactors is not specified in propDict.

So in the BeetstraDrag, if the CoarseGrainingFactors is not specified in the couplingProperties, the coarse-graining value will be overwritten by the value specified in LIGGGHTS.

BeetstraDrag.C line 149-158

    if (typeCG_.size()>1 || typeCG_[0] > 1)
    {
        Info << "Beetstra using scale = " << typeCG_ << endl;
    }
    else if (particleCloud_.cg() > 1)
    {
        scaleDia_=particleCloud_.cg();
        typeCG_[0] = scaleDia_;
        Info << "Beetstra using scale from liggghts cg = " << scaleDia_ << endl;
    }

In both heatTransfer models, the typeCG_[0] is not overwritten. Only the scaledDia_ is updated, however, it is not used during the calculation of the heat transfer coefficient. Suggest to add the same line as in BeetstraDrag typeCG_[0] = scaleDia_ to correct this.

MPIRUN

Hello,everyone.

I have successfully compiled CDFEM (OpenFoam 5.x, Liggghts 3.8), but there are still a problem when running multiphase case, eg dambreak. I try to modify openmpi, etc., but no effect. Any help? Thank you.

Lee

//   run_parallel_cfdemSolverMultiphase_test   //

/home/lee/CFDEM/CFDEMcoupling/tutorials/cfdemSolverMultiphase/damBreak/CFD

rm: cannot remove 'couplingFiles/*': No such file or directory
--------------------------------------------------------------------------
mpirun was unable to find the specified executable file, and therefore
did not launch the job.  This error was first reported for process
rank 0; it may have occurred for other processes as well.

NOTE: A common cause for this error is misspelling a mpirun command
      line parameter option (remember that mpirun interprets the first
      unrecognized command line token as the executable).

Node:       ubuntu
Executable: cfdemSolverMultiphase

Failure to compile the solvers

Hi,

I have OpenFOAM 6 and CFDEMcoupling 24.01.
The following solvers fail to compile:

  • cfdemSolverPisoScalar
  • cfdemSolverIBContinuousForcing
  • cfdemSolverRhoPimpleChem
  • cfdemSolverMultiphase
  • cfdemSolverMultiphaseScalar
  • rctfSpeciesTransport
  • cfdemSolverPisoFreeStreaming

Some errors from console log:

Making dependency list for source file rcfdemSolverRhoSteadyPimpleChem.C
//   log_compileCFDEMcoupling_cfdemSolverRhoPimple_cfdemSolverRhoPimple-2024-07-18-14:16   //
could not open file rhoCombustionModel.H for source file rcfdemSolverRhoSteadyPimpleChem.C due to No such file or directory
wmakeLnIncludeAll: running wmakeLnInclude on dependent libraries:
    wmakeLnInclude error: base directory /home/einhander/OpenFOAM/OpenFOAM-6/src/dynamicMesh/dynamicFvMesh/ does not exist
    Making dependency list for source file rStatAnalysis.C
wmakeLnInclude error: base directory /home/einhander/OpenFOAM/OpenFOAM-6/src/dynamicMesh/dynamicMesh/ does not exist

Failure to compile the solvers

Hi all,

I used "cfdemCompCFDEMall" command to compile the CFDEMcoupling-PFM, which is different from CFDEMcoupling-PUBLIC-5.x. I also had changed the name from "CFDEMcoupling-PFM" to "CFDEMcoupling-PUBLIC-5.x". But I failed to compile it and there was nothing new in home/CFDEM/CFDEMcoupling-PUBLIC-5.x/platforms/linux64GccDPInt32Opt/bin.
I'm new to use Linux/ubuntu so I'm not sure if I compiled it in the right way. Can anyone give me some suggestions?

Kind regards,
Delin.

Dynamic mesh simulations

I was wondering if CFDEMcoupling-PFM can handle dynamic mesh problems where the CFD mesh on OpenFOAM deforms. I am simulating a contracting stomach, therefore the CFD model has complex boundary deformation patterns.

Problem with Installation of CFDEM on University HPC

Hi,
I am trying to install the CFDEM on the TUHH HPC cluster but I am getting the following error.

  1. After cloning with LIGGGHTS-PFM repo, I created an src-build folder.
  2. By using the ccmake ../src ; I updated the CMAKE_BUILD_TYP to release
  3. After running make -j from src-build I am getting this warning message at end:

image
5. On HPC only vtk 8.0.1 version module is available and when I checked for the dependencies of this file, I found that linmpi.so.20 is missing.
6.
image

At the end the log_compilation_is_fail, Is it due to the vtk missing dependency or HPC problem.

Regards
Asif

Coupling files cannot be removed.

when I am running the code cfdemsolverrhopimplechem. I am getting the error "Coupling files cannot be removed". Does anyone know about this. Please reply

Compilation of solvers needs link to python

When I tried to compile solvers with cfdemCompCFDEMsol, it was necessary to link to python. Otherwise, I got many compile errors from libvtkPython***, undefined references. One example is below:
/usr/bin/ld: /usr/lib/libvtkPythonContext2D.so.1: undefined reference to _Py_Dealloc'`

Archlinux 2022.1.1.
gcc (GCC) 11.1.0
cmake version 3.22.2
python3.10
OpenFOAM-6
vtk 9.1

Maybe it was just my issue. But otherwise, it would be nice to include it in the build configuration, so it is not necessary to do it manually.

paths for additional libraries (etc/additionalLibs)

CFDEM_ADD_LIB_PATHS = -I/usr/include/python3.10 -lpython3.10

Cyclic Boundary condition CFDEMcoupling-PFM

Can you please tell me what formulation you are using for imposing periodic boundary condition in CFDEMcoupling-PFM, also refer the files through which you are incorporating ?

Problem about Multiphase

Hello everyone,
I have completely installed OpenFOAM 6 and CFDEM. I want to run the Multiphase dam break case. But I encountered the fault like below:

// run_parallel_cfdemSolverMultiphase_test //

/home/fanyi/CFDEM/CFDEMcoupling/tutorials/cfdemSolverMultiphase/damBreak/CFD

rm: cannot remove 'couplingFiles/*': No such file or directory

--> FOAM FATAL ERROR:
cfdemSolverMultiphase requires OpenFOAM 4.x or 5.x to work properly

FOAM exiting

It seems whether I need to install OpenFOAM 5.x again. How I can link to CFDEM?
Thanks!

Regards,
Fan

Heat and mass coupling fields are not reset when twoWayOne2One is enabled

First of all, thanks for making the framework of twoWayOne2One work. It accelerates scaled-up simulations significantly compared to twoWayMPI.

I was testing the twoWayOne2One scheme (in the 21.11 version) and found that the chemical source and heat transfer terms pushed from LIGGGHTS were accumulating. In theory, they should be reset to zero when entering LIGGGHTS loops. The root cause is that twoWayOne2One does not synchronize the latestpush time as twoWayMPI does. I will explain the finding below:

The following code snippet from fix_cfd_coupling_chemistry.cpp shows the field resetting during the initial_integrate.

void FixCfdCouplingChemistry::initial_integrate(int)
{
    bigint prev_time = update->ntimestep - 1;
    int *mask  = atom->mask;
    int nlocal = atom->nlocal;

    for (int k = 0; k < num_species; ++k)
    {
        if (prev_time == fix_coupling_->latestpush(mod_spec_names_[k]))
        {
            for (int i = 0; i < nlocal; ++i)
            {
                if (mask[i] & groupbit)
                    fix_masschange_[k]->vector_atom[i] = 0.;
            }
        }
    }

However, when the twoWayOne2One is triggered. The if statement if (prev_time == fix_coupling_->latestpush(mod_spec_names_[k])) is never true because latestpush time is not updated. It is always -1 as the value it is initialized. Digging deeper it can be found that the latestpush time can be updated in cfd_datacoupling.cpp

void CfdDatacoupling::push(const char *name, const char *type, void *&, const char *, int iworld)
{
    // for MPI this is called by the library interface
    // check if the requested property was registered by a LIGGGHTS model
    // ie this checks if the model settings of OF and LIGGGHTS fit together
    int found = 0;
    for(int i = 0; i < npush_; i++)
    {
        if(strcmp(name,pushnames_[i]) == 0 && strcmp(type,pushtypes_[i]) == 0)
        {
            found = 1;
            pushinvoked_[i] = 1;

            // TL:
            latestpush_[i] = update->ntimestep;
        }
    ...

So using twoWayOne2One this push function is never called. To help myself understand why I first look into how it is done in twoWayMPI. This push subroutine is called in the following order

  1. subModels/dataExchangeModel/twoWayMPI/twoWayMPI.C:
    in getData calls data_liggghts_to_of
  2. LIGGGHTS/src/library_cfd_coupling.cpp:
    in data_liggghts_to_of calls data_liggghts_to_of_universe
  3. LIGGGHTS/src/library_cfd_coupling.cpp:
    in data_liggghts_to_of_universe calls fcfd->get_dc()->push
  4. LIGGGHTS/src/cfd_datacoupling_mpi.cpp:
    in push calls CfdDatacoupling::push

such that the latestpush time is updated.

My Solution

My solution is basically following the same logic as twoWayMPI. When every time a set of data is pushed to OpenFOAM, trigger this CfdDatacoupling::push so that the latestpush time is updated.

  1. subModels/dataExchangeModel/twoWayOne2One/twoWayOne2One.C:
    in getData calls a new function register_push_liggghts_to_of
void twoWayOne2One::getData
(
    const word& name,
    const word& type,
    double ** const& field,
    label /*step*/
) const
{
    if (name == "x") // the location is transferred by couple()
    {
        return;
    }
    if (type == "vector-atom")
    {
        double **tmp_= static_cast<double **>(lammps_extract_atom(lmp,name.c_str()));
        ... 
        ...
        lig2foam_->exchange<double>
        (
            tmp_,
            lig2foam_vec_tmp_,
            3
        );
        extractCollected<double>
        (
            lig2foam_vec_tmp_,
            const_cast<double**&>(field),
            3
        );
        // let liggghts know field is pushed such that latestPush() is updated // C.C. Modified
        register_push_liggghts_to_of
        (
            name.c_str(),
            type.c_str(),
            lmp,
            (void*&) field,
            "double"
        );
       ...
  1. LIGGGHTS/src/library_cfd_coupling.cpp
    in register_push_liggghts_to_of calls function dc->push
void register_push_liggghts_to_of
(
    const char *name,
    const char *type,
    void *ptr,
    void *&data,
    const char* datatype
)
{
    FixCfdCoupling* fcfd = (FixCfdCoupling*)locate_coupling_fix(ptr);
    CfdDatacouplingOne2One* dc = static_cast<CfdDatacouplingOne2One*>(fcfd->get_dc());

    dc->push(name, type, data, datatype);
}
  1. LIGGGHTS/src/cfd_datacoupling_one2one.cpp:
    remove the error message
void CfdDatacouplingOne2One::push(const char *name,const char *type,void *&to,const char *datatype)
{
    CfdDatacoupling::push(name,type,to,datatype);
  //error->one(FLERR,"Illegal call to CfdDatacouplingOne2One::pull, use with twoWayOne2One");

}

I am not sure about why the error message is original here and what is the consequence to MPI after calling this push.
With this new implementation, the chemical source and heat transfer terms are no longer accumulating over time. They are reset to zero at the first loops of initial_integrate. The latestpull time can also be updated in the similar manner.
I test it with my case and surprisingly the results are exactly the same as that of using twoWayMPI.

Hopefully my report can help solve the trivial issue. I am pretty sure there is another way to update the latestpush time. My solution is just how I tackled this issue. Looking forward to the new release.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.