DLBFoam: Dynamic load balancing for fast reactive simulations

Overview

DLBFoam: Dynamic load balancing for fast reactive simulations

v1.1 OpenFOAM 8

DLBFoam v1.1 - What's new?

DLBFoam v1.1 introduces a fully analytical chemistry Jacobian via pyJac, and optimized ODE solution routines via LAPACK. Combined with the load balancing features, v1.1 provides up to x250 speed-up compared to standard OpenFOAM chemistry model. If you are interested with using only dynamic load balancing without any third party dependency, please use DLBFoam v1.0.

What is DLBFoam?

DLBFoam is an open-source library for OpenFOAM. It introduces dynamic load balancing and a zonal reference mapping model for fast chemistry calculation in parallel simulations. In addition, it also introduces a fully analytical Jacobian formulation and optimized ODE solution routines for further speed-up.

Why do I need this?

Load imbalance in parallel reactive simulations is an issue that causes very long simulation times in OpenFOAM simulations utilizing finite-rate chemistry.

DLBFoam introduces runtime load balancing through MPI routines to minimize the load imbalance between ranks and gain speed-up. The implementation details can be found in our paper [1]. In addition, the cell-wise chemistry problem is vastly improved by the analytical Jacobian formulation and optimized matrix operations in the ODE solver class. The details for those implementations can be found in our follow-up paper [2].

crab pet

Prerequisites

  • OpenFOAM installation (with correct version)
  • LAPACK (Intel-MKL, OpenBLAS or standalone)
  • Cmake
  • ct2foam (Optional)

Compilation

DLBFoam can be compiled by typing the following command after sourcing appropriate OpenFOAM version and making sure a valid LAPACK installation exists:

./Allwmake --clean --platform 

can be MKL, OPENBLAS or STANDALONE.

DLBFoam requires LAPACK packages for improved ODE routines (LAPACKE C interface for OPENBLAS and standalone installation). There are three different ways to provide LAPACK for DLBFoam:

  • Intel-MKL: Install/load Intel-MKL on your workstation/cluster. Installation instructions can be found online. If you are on cluster, you can most probably load it by:

    module load intel-mkl
    

    make sure that the MKLROOT bash variable is defined by typing echo $MKLROOT to your terminal. This option is the fastest option for Intel processors due to optimization of MKL with Intel hardware.

  • OpenBLAS: Install/load OpenBLAS. It may be available on your cluster as a module, similar to Intel-MKL. Make sure that the OPENBLAS_INSTALL_ROOT bash variable is defined by typing echo $OPENBLAS_INSTALL_ROOT, and define it in your bashrc if it is not.

  • Standalone: A standalone installation may be a good idea if you are on your personal workstation and not on a cluster. Install LAPACKE-dev libraries by:

    (sudo) apt-get install liblapacke-dev
    

Mechanism generation

After the successful compilation, the C subroutines generated by the pyJac for the analytical Jacobian should be compiled and linked to the OpenFOAM case folder.

In this repository, we provide the input files and C subroutines generated by pyJac for GRI-3.0, Yao, and DRM-19 mechanisms. If you want to use one of these mechanisms, no other dependency is required (except a CMake installation).

  • Go to the utilities/ folder, and execute Allrun as:
./Allrun -m 

where is gri30, yao, or drm19. This command will generate a folder called foam_mech, which contains the chemical mechanism input files and a library generated from the files generated by pyJac. You need to put this folder to your simulation case and link it through controlDict, as explained in the next section.

If you want to use a different chemical mechanism, you need to create the thermo input files in a format required by OpenFOAM, as well as analytical Jacobian C subroutines generated by pyJac. This process requires many dependencies, most notably Cantera and pyJac.

We have developed a tool called ct2foam that makes this process a lot easier. Please check ct2foam (and the pyjac2foam utility in it) if you are interested in using a different mechanism.

Usage

Once the compilation is successful, any case running with standard OpenFOAM can be easily converted to use DLBFOAM, following these steps:

  • The DLBFoam should be linked to the solver. Add the following to your system/controlDict file:
libs
(
    "libchemistryModel_DLB.so" 
    "libODE_DLB.so"
    "$FOAM_CASE/constant/foam_mech/libc_pyjac.so"
);

the first two libraries link the DLBFoam and the optimized LAPACK solvers, while the last library links the C subroutines generated in the previous section for the analytical Jacobian.

  • Select chemistry solver as ode_LAPACK and the method as loadBalanced_pyJac in constant/chemistryProperties:
chemistryType
{
    solver          ode_LAPACK;
    method          loadBalanced_pyJac;
}
  • Add the loadbalancing subdictionary to the same chemistryProperties file:
loadbalancing
{
    active true;
    log	true;
}
  • Set the solver flag under odeCoeffs to seulex_LAPACK in order to use the optimized ODE solvers:
odeCoeffs
{
    solver          seulex_LAPACK;
    absTol          1e-08;
    relTol          1e-05;
}
  • (Optional) Set the refmapping as active in chemistryProperties file if you want to use the reference mapping method (you have to add an empty refmapping{} dict even if you do not use it):
refmapping
{
    active  true;
    
    mixtureFractionProperties
    {
        oxidizerMassFractions
        {
            N2       0.77;
            O2       0.23;
        }

        fuelMassFractions
        {
            NC12H26       1.0;
        }

        #include "$FOAM_CASE/constant/foam_mech/thermo.foam"
    }
    tolerance	1e-4;  // mixture fraction tolerance
    deltaT	2; // temperature tolerance
}

Reference mapping uses mixture fraction (Z) and maps a reference solution to reference cells satisfying a condition.

The entry above sets the Z=0 and Z=1 conditions from given mass fractions. For each CFD iteration it finds a reference solution where Z

(Optional) When deltaT is explicitly set, the mapper also checks the temperature between reference solution and other reference cells and ensures: abs(Tcell-Tref)

  • Run the case normally with OpenFOAM's reactive solvers.

For a working example, check the tutorials given in tutorials folder.

Contributors

Getting help and reporting bugs

Please submit a GitHub issue if you found a bug in the program. If you need help with the software or have further questions, either open an issue or contact the contributors.

Citation

If you use our model, please cite the publication describing its implementation, Refs. [1] and [2].

References

[1] B. Tekgül, P. Peltonen, H. Kahila, O. Kaario, V. Vuorinen, DLBFoam: An open-source dynamic load balancing model for fast reacting flow simulations in OpenFOAM, arXiv preprint arXiv:2011.07978 (2020).

BibTex

@article{tekgul2020dlbfoam,
  title={DLBFoam: An open-source dynamic load balancing model for fast reacting flow simulations in OpenFOAM},
  author={Tekg{\"u}l, Bulut and Peltonen, Petteri and Kahila, Heikki and Kaario, Ossi and Vuorinen, Ville},
  journal={arXiv preprint arXiv:2011.07978},
  year={2020}
}

[2] I. Morev, B. Tekgül, M. Gadalla, A. Shahanaghi, J. Kannan, S. Karimkashi, O. Kaario, V. Vuorinen, Fast reactive flow simulations using analytical Jacobian and dynamic load balancing in OpenFOAM, arXiv preprint arXiv:2105.12070 (2021).

BibTex

@article{morev2021fast,
  title={Fast reactive flow simulations using analytical Jacobian and dynamic load balancing in OpenFOAM},
  author={Morev, Ilya and Tekg{\"u}l, Bulut and Gadalla, Mahmoud and Shahanaghi, Ali and Kannan, Jeevananthan and Karimkashi, Shervin and Kaario, Ossi and Vuorinen, Ville},
  journal={arXiv preprint arXiv:2105.12070},
  year={2021}
}

Comments
  • PYJAC_NSP error

    PYJAC_NSP error

    Hello,

    I keep getting this error for a new mechanism file. I want to use the FFCM-1 mechanism and for that, I compiled everything using the ct2foam utility. I even compiled DLBFoam from scratch but it keeps saying that /lib/libchemistryModel_DLB.so: undefined symbol: PYJAC_NSP. How can I solve this problem? chem.foam and therm.foam in the foam_mech_files folder are also correct.

    Thanks.

    opened by drhcelik 24
  • Solver crashed when using reduced mechanism

    Solver crashed when using reduced mechanism

    Note: if this is not a issue, please close it.

    I finally compiled the DLBFoam on Ubuntu with OpenFOAM9. My case is runnable with GRI30 mechnism. I also tested Syngas/NOx (2017) mechanism (https://www.universityofgalway.ie/combustionchemistrycentre/mechanismdownloads/#)

    However, when I using reduced mechanism (Azevedo mechanism as attached zip file) to run the same case, it crashed from the first step. AZ.zip

    On the contrary, running the case with Azevedo mechanism but not using ode_pyJac solver is okay. That means the mechanism is acceptable on ode solver. I wonder where might go wrong with the reduced mechnism and ode_pyJac?

    Thank you.

    Regards, Mactone

    `Time scales min/max: Flow = 1.57096767e-09, 1e-05 Temperature = 4.49423284e+307, 4.49423284e+307 Composition = 4.49423284e+307, 4.49423284e+307 Overall = 1.57096767e-09, 1e-05 Time = 25002

    diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::sigFpe::sigHandler(int) at ??:? #2 ? in "/lib/x86_64-linux-gnu/libc.so.6" #3 feraiseexcept in "/lib/x86_64-linux-gnu/libm.so.6" #4 log in "/lib/x86_64-linux-gnu/libm.so.6" #5 eval_rxn_rates at ??:? #6 eval_jacob at ??:? #7 Foam::loadBalanced_pyJacChemistryModel<Foam::sutherlandTransport<Foam::species::thermo<Foam::janafThermo<Foam::perfectGasFoam::specie >, Foam::sensibleEnthalpy> > >::jacobian(double, Foam::Field const&, int, Foam::Field&, Foam::SquareMatrix&) const at ??:? #8 Foam::seulex_LAPACK::solve(double&, Foam::Field&, int, Foam::ODESolver::stepState&) const at ??:? #9 Foam::ODESolver::solve(double, double, Foam::Field&, int, double&) const at ??:? #10 Foam::ode_pyJac<Foam::loadBalanced_pyJacChemistryModel<Foam::sutherlandTransport<Foam::species::thermo<Foam::janafThermo<Foam::perfectGasFoam::specie >, Foam::sensibleEnthalpy> > > >::solve(double&, double&, Foam::Field&, int, double&, double&) const at ??:? #11 Foam::loadBalancedChemistryModel<Foam::sutherlandTransport<Foam::species::thermo<Foam::janafThermo<Foam::perfectGasFoam::specie >, Foam::sensibleEnthalpy> > >::solveSingle(Foam::ChemistryProblem&, Foam::ChemistrySolution&) const at ??:? #12 AZ.zip Foam::loadBalancedChemistryModel<Foam::sutherlandTransport<Foam::species::thermo<Foam::janafThermo<Foam::perfectGasFoam::specie >, Foam::sensibleEnthalpy> > >::solveList(Foam::UListFoam::ChemistryProblem&) const at ??:? #13 double Foam::loadBalancedChemistryModel<Foam::sutherlandTransport<Foam::species::thermo<Foam::janafThermo<Foam::perfectGasFoam::specie >, Foam::sensibleEnthalpy> > >::solve<Foam::Field >(Foam::Field const&) at ??:? #14 Foam::combustionModels::laminar::correct() at ??:? #15 Foam::combustionModels::PaSR::correct() at ??:? #16 ? in "/opt/openfoam9/platforms/linux64GccDPInt32Opt/bin/reactingFoam" #17 ? in "/lib/x86_64-linux-gnu/libc.so.6" #18 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6" #19 ? in "/opt/openfoam9/platforms/linux64GccDPInt32Opt/bin/reactingFoam"`

    opened by mactone 10
  • OpenFOAM 9 and dev support implemented

    OpenFOAM 9 and dev support implemented

    Present update adds support for OpenFOAM 9 and dev. Compilation is tested successfully.

    However, there are still certain streamlining in general I'm planning to do and will continue developing my of-dev branch in my fork. We can communicate here regarding those actions as well depending when you're ready to merge.

    See e.g. OFdev_update.txt to see some basic things that required modification in the new OF-9/dev update.

    -HK

    opened by kahilah 9
  • Sanity check in seulex_LAPACK class methods raise warnings on built-in tutorials

    Sanity check in seulex_LAPACK class methods raise warnings on built-in tutorials

    Before describing the issue, I have to mention this could be just related to stock OpenFOAM case setups, and not DLBFoam!!!

    So, in this link there is a sanity check to ensure temperature values, computed in the solve vector, keep within the prescribed limits of NASA polynomials. So far, this is just additional check which is good.

    On another note, in the standard ODE implementation of SEULEX, there's no sanity check for temperature, which is also understandable as the class is derived from a generic ODE library that should operate on any solve vector for stiff ODEs and not necessarily be containing temperature. Therefore, avoiding this sanity check in standard class is also understandable, from the code design perspective.

    Now, the problem comes when trying to use DLBFoam on built-in tutorials, particularly the counterFlowFlame2D_GRI. There, warnings are raised as temperature goes off the temperature bounds of NASA polynoms. This can be quite misleading that the problem is in DLBFoam (which it is NOT) as being the one generating warnings in the application log, while standard model works as a charm!

    Here, I am not sure whether the problem is just the configuration/BC of the counterFlowFlame2D_GRI (because @moreff has also witnessed similar problems on other tutorials) or this could be in standard implementation of SEULEX? Should that sanity check be completely removed, and we just acknowledge SEULEX implementation as it is in stock OpenFOAM, to avoid misleading interpretation of those warnings?

    invalid 
    opened by mahgadalla 8
  • Polynomial type fits of mechanism transport data need to be 7th order

    Polynomial type fits of mechanism transport data need to be 7th order

    Apparently the mechanism data IN THE TUTORIALS have been generated for 3rd order polynomial fits, consistently with Cantera and Chemkin. While this is not a problem for Sutherland models, using e.g. logPolynomial models results in OpenFOAM crashes due to that OpenFOAM forces 7th order polynomials. The package ct2foam/pyjac2foam can be utilized to properly generate the 7th order polynomial type fits of the mechanism transport data.

    opened by mahgadalla 7
  • "FAQ" part to README

    There should be a FAQ part in the README.

    For example, from experience I know that when using pyjac, it is very easy to get an error:

    /path/to/user/OpenFoam/linux64GccDPInt32Opt/lib/libchemistryModel_DLB.so:
     undefined symbol: eval_h
    

    README should state that in this occasion you pyjac library linkin is not established. Fix it like ....

    opened by kahilah 7
  • Poor naming of /chemistrySolvers/ode_LAPACK

    Poor naming of /chemistrySolvers/ode_LAPACK

    At the moment the chemistrySolver type ode_LAPACK is poorly named. The code there is related to pyjac usage only and has nothing to do with Lapack. Hence, renaming should be done for chemistrySolvers/ode_LAPACK

    opened by kahilah 7
  • Error in PSRTest (DLBFoam v1.1)

    Error in PSRTest (DLBFoam v1.1)

    Hello all,

    During compilation of DLBFoam v1.1, I am facing a problem in the test after the compilation. It would be nice if you could support me to solve this.

    When executing Allwmake script, after the PSRTest section, there will be an error.

    Allwmake (Excerpt):

    .
    .
    pushd tests/validation/pyjacTests/PSRTest  > /dev/null
        ./runTests.sh
    popd  > /dev/null
    .
    .
    

    Here is a part of the error message: (full log in the attachment)

    *** Error in `./PSRTest.bin': corrupted size vs. prev_size: 0x00000000020589c0 ***
    ======= Backtrace: =========
    /lib64/libc.so.6(__libc_start_main+0xfc)[0x7f291da8555c]
    .
    .
    .
    ./PSRTest.bin[0x414ba9]
    ======= Memory map: ========
    00400000-0050d000 r-xp 00000000 3d8:ad14e 144128597299383036             /work/00/gs50/s50001/OpenFOAM/s50001-8/run/DLBFoam/tests/validation/pyjacTests/PSRTest/PSRTest.bin
    .
    .
    .
    7f291e045000-7f291e046000 r--p 00014000 08:02 3224768                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1./runTests.sh: line 11: 45017 Aborted                 ./PSRTest.bin -case testCase
    
    Validation FAILED.
    See output above for further information.
    
    Test error control on mechanism consistency in pyjacLoadBalancedChemistryModel:
    *** Error in `./PSRTest.bin': corrupted size vs. prev_size: 0x00000000028e09c0 ***
    ./runTests.sh: line 28: 45044 Segmentation fault      ./PSRTest.bin -case testCase > /dev/null 2>&1
    FAILED. pyjacLoadBalancedChemistryModel.C did not catch the species mismatch error.
    

    My OpenFOAM version is 8 and it is compiled with intel compiler and intelMPI. Somehow the installation with gcc and standalone didn’t work.

    I tested this with the main branch as well as with the OF8 v1.1 tag.

    Here are the information for my machine: https://www.cc.u-tokyo.ac.jp/en/supercomputer/obcx/system.php

    I hope you can help me out 🙇🏻‍♂️

    Thank you in advance

    Kazuma Kunihara

    log.Allwmake.txt

    opened by kazumamatata 5
  • DLBFoam v1.1 for OpenFoam ESI version ?

    DLBFoam v1.1 for OpenFoam ESI version ?

    Hello!

    Currently I am planning to use DLBFoam for my research. However our supercomputer does only support the ESI version of OpenFoam (v2106). Is there any version of DLBFoam v1.1 for v2106 or v2006 that can be shared?

    If not, how much would be the work load to implement the support for v2106?

    opened by kazumamatata 5
  • Change of state variable OFv10 onwards

    Change of state variable OFv10 onwards

    I know v1.1_OF10 branch is still in dev, but I just wanted to leave this issue here as a reminder that OpenFOAM switched the main state variable in chemistry class to mass fraction in v10 (https://github.com/OpenFOAM/OpenFOAM-10/commit/4f0dfc3bdf09ae6cf9caf0b806af6fabf3002186), which needs to be reflected within DLBFoam, especially v1.0 without pyJac. This includes refactoring the "getVariables" approach to differentiate between mass fraction and concentration state variables between pyjac and no-pyjac approaches, as well as the updateReactionRate function that differs between two chemistry models.

    opened by blttkgl 4
  • OF9 version crashes when polynomial transport is used

    OF9 version crashes when polynomial transport is used

    In OpenFOAM 9, a dynamic compilation of thermo and chemistry was introduced and some of the combinations are not compiled in standard library. https://github.com/OpenFOAM/OpenFOAM-dev/commit/974712b2bdb05a1e2e736e61bca49a88cd08cda0

    This leads to a crash when DLBFoam is used with e.g. polynomial transport:

    --> FOAM FATAL IO ERROR:
    Unknown solver type ode_pyJac
    Supported solver types:
    3
    (
    ode
    none
    EulerImplicit
    )
    
    file: /opt/openfoam9/etc/codeTemplates/dynamicCode/basicChemistryModel from line 17 to line 35.
    
        From function void Foam::compileTemplate::setFilterVariable(Foam::dynamicCode&, const Foam::dynamicCodeContext&, const Foam::Pair<Foam::word>&) const
        in file db/dynamicLibrary/compileTemplate/compileTemplate.C at line 81.
    
    FOAM exiting
    
    bug 
    opened by moreff 4
  • ISAT compatibility

    ISAT compatibility

    I now have a branch on my fork where I extended ISAT to DLBFoam, and currently working on extending it to pyJac solvers: https://github.com/blttkgl/DLBFoam/tree/v1.1_OF10_ISAT

    I am opening this issue to act as a placeholder, and let you know what we have under works for a near pull request.

    Bulut

    enhancement 
    opened by blttkgl 0
  • Compile error with DLBFoam STANDALONE Lapack

    Compile error with DLBFoam STANDALONE Lapack

    Hello again,

    I wanted to report other issue I encounter when compiling DLBFoam v1.1_OF8. To avoid intel MKL or other compilation problem , now I am trying to compile DLBFoam v1.1 with the STANDALONE lapack. I am running OpenFOAM 8 provided by the supercomputer center, which uses gcc compiler and intelMPI. (That should be compiled properly and also validated).

    However, there are some error message regarding the lapack.

    I assume that is, caused by the wrong Lapack version. So my question: Can I ask you which lapack version you have tested? My version is 3.10, downloaded from: http://www.netlib.org/lapack/

    Here is the error message: What do you think?

    [[email protected] DLBFoam]$ ./Allwmake --platform STANDALONE
    wmake libso src/thermophysicalModels/chemistryModel
    wmake libso src/ODE_DLB
    wmakeLnInclude: linking include files to ./lnInclude
    Making dependency list for source file seulex_LAPACK.C
    g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/usr/include    -I/work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include  -DDEBUG=0  -IlnInclude -I. -I/work/opt/local/apps/gcc/4.8.5/impi/2019.9.304/openfoam/8/OpenFOAM-8/src/OpenFOAM/lnInclude -I/work/opt/local/apps/gcc/4.8.5/impi/2019.9.304/openfoam/8/OpenFOAM-8/src/OSspecific/POSIX/lnInclude   -fPIC -c ODESolvers/ODESolver/ODESolver.C -o Make/linux64GccDPInt32Opt/ODESolvers/ODESolver/ODESolver.o
    g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/usr/include    -I/work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include  -DDEBUG=0  -IlnInclude -I. -I/work/opt/local/apps/gcc/4.8.5/impi/2019.9.304/openfoam/8/OpenFOAM-8/src/OpenFOAM/lnInclude -I/work/opt/local/apps/gcc/4.8.5/impi/2019.9.304/openfoam/8/OpenFOAM-8/src/OSspecific/POSIX/lnInclude   -fPIC -c ODESolvers/ODESolver/ODESolverNew.C -o Make/linux64GccDPInt32Opt/ODESolvers/ODESolver/ODESolverNew.o
    g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3  -DNoRepository -ftemplate-depth-100 -I/usr/include    -I/work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include  -DDEBUG=0  -IlnInclude -I. -I/work/opt/local/apps/gcc/4.8.5/impi/2019.9.304/openfoam/8/OpenFOAM-8/src/OpenFOAM/lnInclude -I/work/opt/local/apps/gcc/4.8.5/impi/2019.9.304/openfoam/8/OpenFOAM-8/src/OSspecific/POSIX/lnInclude   -fPIC -c ODESolvers/seulex_LAPACK/seulex_LAPACK.C -o Make/linux64GccDPInt32Opt/ODESolvers/seulex_LAPACK/seulex_LAPACK.o
    ODESolvers/seulex_LAPACK/seulex_LAPACK.C: In member function ‘bool Foam::seulex_LAPACK::seul(Foam::scalar, const scalarField&, Foam::label, Foam::scalar, Foam::label, Foam::scalarField&, const scalarField&) const’:
    ODESolvers/seulex_LAPACK/seulex_LAPACK.C:157:53: error: too few arguments to function ‘void dgetrs_(const char*, const int*, const int*, const double*, const int*, const int*, double*, const int*, int*, size_t)’
         dgetrs_(&TRANS,&N,&NRHS,A,&LDA,IPIV,b,&LDB,&INFO);
                                                         ^
    In file included from /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapack.h:11:0,
                     from /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapacke.h:36,
                     from ODESolvers/seulex_LAPACK/seulex_LAPACK.H:58,
                     from ODESolvers/seulex_LAPACK/seulex_LAPACK.C:28:
    /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapack.h:4043:42: note: declared here
     #define LAPACK_dgetrs_base LAPACK_GLOBAL(dgetrs,DGETRS)
                                              ^
    /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapacke_mangling.h:12:39: note: in definition of macro ‘LAPACK_GLOBAL’
     #define LAPACK_GLOBAL(lcname,UCNAME)  lcname##_
                                           ^
    /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapack.h:4044:6: note: in expansion of macro ‘LAPACK_dgetrs_base’
     void LAPACK_dgetrs_base(
          ^
    ODESolvers/seulex_LAPACK/seulex_LAPACK.C:211:61: error: too few arguments to function ‘void dgetrs_(const char*, const int*, const int*, const double*, const int*, const int*, double*, const int*, int*, size_t)’
                 dgetrs_(&TRANS,&N,&NRHS,A,&LDA,IPIV,b,&LDB,&INFO);
                                                                 ^
    In file included from /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapack.h:11:0,
                     from /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapacke.h:36,
                     from ODESolvers/seulex_LAPACK/seulex_LAPACK.H:58,
                     from ODESolvers/seulex_LAPACK/seulex_LAPACK.C:28:
    /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapack.h:4043:42: note: declared here
     #define LAPACK_dgetrs_base LAPACK_GLOBAL(dgetrs,DGETRS)
                                              ^
    /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapacke_mangling.h:12:39: note: in definition of macro ‘LAPACK_GLOBAL’
     #define LAPACK_GLOBAL(lcname,UCNAME)  lcname##_
                                           ^
    /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapack.h:4044:6: note: in expansion of macro ‘LAPACK_dgetrs_base’
     void LAPACK_dgetrs_base(
          ^
    ODESolvers/seulex_LAPACK/seulex_LAPACK.C:268:57: error: too few arguments to function ‘void dgetrs_(const char*, const int*, const int*, const double*, const int*, const int*, double*, const int*, int*, size_t)’
             dgetrs_(&TRANS,&N,&NRHS,A,&LDA,IPIV,b,&LDB,&INFO);
                                                             ^
    In file included from /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapack.h:11:0,
                     from /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapacke.h:36,
                     from ODESolvers/seulex_LAPACK/seulex_LAPACK.H:58,
                     from ODESolvers/seulex_LAPACK/seulex_LAPACK.C:28:
    /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapack.h:4043:42: note: declared here
     #define LAPACK_dgetrs_base LAPACK_GLOBAL(dgetrs,DGETRS)
                                              ^
    /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapacke_mangling.h:12:39: note: in definition of macro ‘LAPACK_GLOBAL’
     #define LAPACK_GLOBAL(lcname,UCNAME)  lcname##_
                                           ^
    /work/00/gs50/s50001/lapack-3.10.1/LAPACKE/include/lapack.h:4044:6: note: in expansion of macro ‘LAPACK_dgetrs_base’
     void LAPACK_dgetrs_base(
          ^
    make: *** [Make/linux64GccDPInt32Opt/ODESolvers/seulex_LAPACK/seulex_LAPACK.o] Error 1
    
    opened by kazumamatata 26
Releases(v1.1.0_OF8)
  • v1.1.0_OF8(Aug 14, 2022)

    DLBFoam v1.1 stable release for OpenFOAM-8. The simulations performed in the implementation paper (https://doi.org/10.1063/5.0077437) are performed with this release

    Source code(tar.gz)
    Source code(zip)
Owner
Aalto-CFD
Aalto Energy Conversion: Computational thermo-fluids laboratory in energy and combustion research.
Aalto-CFD
Code of balancing robot with DC motors

BalancingrobotDC Code of balancing robot with DC motors Balancing robot with 6V DC motors L293D IC as motor driver (powered by 5V pin of arduino) MPU6

null 1 Nov 14, 2021
An implementation of a Windows loader that can load dynamic-linked libraries (DLLs) directly from memory

memory-module-loader memory-module-loader is an implementation of a Windows loader that can load dynamic-link libraries (DLLs) directly from memory. T

SCYTHE 118 Nov 21, 2022
Open-source node system framework, to change your algorithmic code into useful tools to create much more complicated simulations!

Open-source node system framework, to change your algorithmic code into useful tools to create much more complicated simulations!

Zenus Technology 763 Jan 9, 2023
Ureact - Minimalistic reactive library for c++

µReact µReact is an open-source minimalistic single-header reactive programming library for C++17. ❗️ This library is a work-in-progress. It should no

Yaroslav 126 Nov 27, 2022
Event-driven molecular dynamics simulations for hard spheres

Event-driven molecular dynamics code for hard spheres This is an event-driven molecular dynamics (EDMD) code for hard spheres. It uses neighbor lists

null 11 Nov 14, 2022
C++React: A reactive programming library for C++11.

C++React is reactive programming library for C++14. It enables the declarative definition of data dependencies between state and event flows. Based on

Sebastian 969 Jan 3, 2023
C++11 provides chainable and iterable object for uniform die casts. Useful for statistics or table top RPG simulations.

12/1/2018 Due to feedback about compile-time limitations, the api has been changed since release. The api now supports user-defined literals which mak

null 12 Sep 5, 2021
An experimental sprite rendering setup utilizing SSBO's, Threading, EnTT reactive systems, and array-textures based sprite caching.

entt-reactive An experimental sprite rendering setup utilizing pooled SSBO's, a multithreaded setup based on Even Todd's The Poor Man's Threading Arch

Jackie Fuchs 7 Apr 29, 2022
dwm is an extremely fast, small, and dynamic window manager for X.

dwm - dynamic window manager dwm is an extremely fast, small, and dynamic window manager for X. My Patches This is in the order that I patched everyth

Christian Chiarulli 32 Dec 23, 2022
Blade - A simple, fast, clean, and dynamic language that allows you to develop complex applications quickly.

The Blade Programming Language Quick links: BUILDING | CONTRIBUTING | DOCS | LICENSE | tl;dr Blade is a simple, fast, clean and dynamic language that

Blade Programming Language 121 Dec 31, 2022
Control Heidelberg Wallbox Energy Control over WiFi using ESP8266 and configure your own local load management

< scroll down for English version and additional information > wbec WLAN-Anbindung der Heidelberg WallBox Energy Control über ESP8266 Die Heidelberg W

null 95 Jan 3, 2023
Automatically load dlls into any executables without replacing any files!

Automatically loaded dll using xinput9_1_0 proxy. Please put the modified xinput9_1_0.dll in the executable's directory.

null 14 Dec 24, 2022
Remap ELF LOAD segments to huge pages

Quick start Not recommended as a production solution, but it's a very fast way to benchmark if your application benefits from remapping your text and

null 19 Dec 21, 2022
Living off the Land Attack in Linux, load an anonymous file in memory.

ELFMemoryLoader Living off the Land Attack in Linux。 Linux场景下的核心载荷不落地攻击。 Loader get elf data from remote server, then use file descriptor to run elf i

null 5 Sep 24, 2022
Generate huge load-avg

Loadavg-generator Will create a lot of threads, limited to 2 CPUs to avoid hanging the system. Code is avoiding pthread to avoid eating too much memor

Adrien Mahieux 7 Jul 6, 2022
Stock exchange simulator made in Swing using Java with logic backend in C++ giving it faster load time and better data control

StockSimulator Stock exchange simulator made in Swing using Java with logic backend in C++ giving it faster load time and better data control Features

Dušan Todorović 0 Mar 1, 2022
Arduino Based Electronic DC Load.

ArduDCLoad A configurable multipurpose DC Load board developed directly on Twitch The values of the resistors can be calculated to adapt the PCB to yo

Laboratorio Gluon 2 Feb 19, 2022
Load bitstream to AG1K series FPGA using CH552

ch552-ag1k-msd Load bitstream to AG1K series FPGA using CH552 AG1K does not have a built-in data flash; This design only simulate a USB mass storage d

libc0607 6 Dec 14, 2022
Kernel Load Balancer

klb klb means "Kernel Load Balancer". It is a (user-space) daemon which acts as a bridge between Linux IPVS and Zeroconf. IPVS services are populated

CM4all GmbH 3 Dec 14, 2022