DLBFoam: An open-source dynamic load balancing model for fast reacting flow simulations in OpenFOAM. https://doi.org/10.1016/j.cpc.2021.108073, https://doi.org/10.1063/5.0077437
License: GNU General Public License v3.0
Hey,
Shouldn't be this line and two bottom of that something like 2.0 * dict.lookupOrDefault<label>("C", 0) / thermo.Wi(i).value());
and this something like this:
bool Hcheck0b = validatePyjacEnthalpy(Y, 298.15, thermo.ha().ref()[0]-thermo.hs().ref()[0], 1e-6);
At least this was the only way to compile on CSC using latest OF-dev module for me.
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
It seems that the mechanism data is missing in the shear layer pyJac tutorial?
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"`
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
I haven't entirely tracked down what's happening here, but the build is failing because it can't link libc_pyjac_test.so. I find this in the build directory, but it's a symlink to itself. If I remove the symlink command in runCmake.sh, then it libc_pyjac_test.so does not exist.
Hi, I try to slove a high Ma number field with parallel rhoReactingFoam, with mechanism of GRI3.0. The mechanism has been translated into *.foam files, and loadBalance is applied. My chemistrylProperties settings:
refmapping
{
active true;
mixtureFractionProperties
{
oxidizerMassFractions
{
N2 0.8;
O2 0.2;
}
fuelMassFractions
{
C2H4 1;
}
#include "$FOAM_CASE/chemkin/therm.foam";
}
tolerance 1e-8;
}
chemistry on;
initialChemicalTimeStep 1.0e-10;
loadbalancing
{
active true;
log true;
}
chemistryType
{
solver EulerImplicit;
method loadBalanced;
}
EulerImplicitCoeffs
{
cTauChem 1;
equilibriumRateLimiter on;
}
odeCoeffs
{
solver seulex;
absTol 1e-08;
relTol 1e-05;
}
#include "$FOAM_CASE/chemkin/rea.foam";
It works for two steps, as log has reported the loadBalance results.
[202] Sender rank: 202 sends to: "(68 69 )" counts: "(1441 3832 )" remaining problems: 4477
Then it reports error, where different cores report different errors:
DILUPBiCGStab: Solving for Uz, Initial residual = 6.68677e-05, Final residual = 2.46475e-11, No Iterations 1
[65] --> FOAM FATAL IO ERROR:
[65] Wrong token type - expected scalar value, found on line 0: word 'z'
[117] Bad token - could not get int32
[17] Bad token - could not get scalar value
If i change chemistryType method into standard, it can normally run, so i think this would be a DLBfoam error.
Much gratitude if you have any suggestions.
At the moment we define DLBEulerImplicitChemistrySolvers.C which is not really relevant from the practical use point of view. These parts could be dropped to simplify the code base.
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?
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.
Hey,
Allwmake_Aalto script doesn't compile the ODE_DLB library for the PUHTI and MAHTI platform.
This issue can be solved by changing appropriate lines of the Allwmake_Aalto script from
cp src/ODE_DLB/Make/options.mahti src/ODE_DLB/Make/options
to
cp src/ODE_DLB/Make/options.openblas src/ODE_DLB/Make/options
and
cp src/ODE_DLB/Make/options.puhti src/ODE_DLB/Make/options
to
cp src/ODE_DLB/Make/options.mkl src/ODE_DLB/Make/options
Thanks!
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 (OpenFOAM/OpenFOAM-10@4f0dfc3), 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.
It would be extremely beneficial if the tests/validation and tutorials would share the thermo/mech inputs in the exactly same manner what ct2foam provides as standard output.
Would be much easier to understand for a new user who needs to learn the whole workflow.
At the moment user will be puzzled when he wants to run a pyjac tutorial and it's not possible without properly compiling and linking pyjac in the case folder. This is not desired.
Utilise the pre-compiled mechanism in similar way as in e.g. testing class so the tutorial is directly runnable.
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
Hello!
Allwmake_Aalto script doesn't compile the ODE_DLB library for the DESKTOP platform.
This issue can be solved by changing line 41 of the Allwmake_Aalto script from
cp src/ODE_DLB/Make/options.desktop src/ODE_DLB/Make/options
to
cp src/ODE_DLB/Make/options.standalone src/ODE_DLB/Make/options
Thanks!
Hello,
I run an ECN case using ode_pyJac solver with loadbalanced_pyjc method. This case works well.
However, when I change to ode solver with loadbalanced method, the case did not show any chemistry iterations excluding C12H26, O2, CO2, and H2O.
This is odd to me.
Do you know what the reason is? Looking forward to your help.
thanks a lot
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 ....
In OpenFOAM 9, a dynamic compilation of thermo and chemistry was introduced and some of the combinations are not compiled in standard library.
OpenFOAM/OpenFOAM-dev@974712b
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
Catch2 v2.9.2 and hence the unit tests don't compile with newer glibc versions, where MINSIGSTKSZ is not longer defined as a constant (more info at catchorg/Catch2#2178). It is fixed since version v2.13.5 and the catch.hpp headerfile should be updated with a newer version. Defining it as a constant worked as a temporary fix for me.
Also some user modifications is required in ODE_DLB/Make/options.mkl file if MKL is installed from Ubuntu's repositories. By default, headers and libraries are installed into separate folders /usr/include/mkl and /usr/lib/x86_64-linux-gnu/mkl/, but the include and linking paths are defined as -L${MKLROOT}/lib/intel64/ and -I${MKLROOT}/include/ in the project.
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?
[s50001@cx0010 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
OpenFOAM v9 introduced a change in how chemistry is calculated, by not updating the thermophysical properties of the cell within the PIMPLE loop. Since the chemistry integration occurs within the simulation timestep, it should be initialised with old time properties. At the moment this is not the case. I attach the commit below and keep this issue active to be addressed later for v9 and v10 distributions.
Hi,
I am trying to convert a detailed CRECK mechanism (492 species and 17790 reaction mechanism - http://creckmodeling.chem.polimi.it/menu-kinetics/menu-kinetics-detailed-mechanisms/107-category-kinetic-mechanisms/403-mechanisms-1911-tot-ht-lt).
While running the pyjac2foam.sh, it reports a formatting error, however, while looking at the reaction mechanism, it is not the case.
I am attaching the error and outfile along with the jacobian file where it is being reported as an error.
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?
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.
Hey,
The function tc() that calculates the chemical time scale in chemistryModel uses the reaction coefficients from the stock chemistry solver to calculate a chemical time scale. This chemical time scale is then could be used in combustionModel for various TCI models, such as PaSR. Currently this function is not implemented in loadBalancedChemistryModel_pyJac, which leads to a flawed setup if a user uses a TCI model with pyJac setup. Until this feature is implemented, I suggest it is overridden as notImplemented in the model following legacy pyjac model, so the user will see an error message when they try this combination.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.