Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a function mechInfo() to return compiled mechanism information #40

Open
blttkgl opened this issue Feb 15, 2021 · 2 comments
Open

Add a function mechInfo() to return compiled mechanism information #40

blttkgl opened this issue Feb 15, 2021 · 2 comments

Comments

@blttkgl
Copy link

blttkgl commented Feb 15, 2021

Hey,

We use pyJac with linking it to OpenFOAM as a dynamic library through case folders. During compiling the OpenFOAM chemistry model we use dummy pyjac headers, since we want to be able to use different mechanisms via pyJac by linking the appropriate dynamic library from the case folder.

At the moment there is no easy way to check if the mechanism input file provided and mechanism pyJac is compiled and dynamically linked are matching. Since header files are dummy (so we are not limited to one mechanism), we can't for instance check number of species NSP, since it is #defined in the mechanism.h.

Would you be able to add a get_mech_info() function, which returns the mechanism information such as number of species, number of variables, forward reactions etc. when called? If this is implemented it enables OpenFOAM users to use multiple mechanisms without re-compiling their models, by simply checking e.g. pyJac mechanism size matches the mechanism they want to use.

I can also try to provide this change and open a pull request if you are interested.

Thanks!

Bulut

@kyleniemeyer
Copy link
Member

Hi @blttkgl, thanks for your interest! I/we aren't actively developing pyJac at this time, but I'd be happy to look at a pull request.

However, I am a bit confused about

If this is implemented it enables OpenFOAM users to use multiple mechanisms without re-compiling their models, by simply checking e.g. pyJac mechanism size matches the mechanism they want to use.

Is the idea that you have compiled OpenFOAM for a particular model size, but could vary the chemistry model by only updating the output from pyJac, without recompiling everything else?

@blttkgl
Copy link
Author

blttkgl commented Feb 19, 2021

Hey @kyleniemeyer !

Yes, that's correct. We link the header files of a (any) pyJac output to our chemistryModel, so that the pyJac functions are defined during model compilation via headers. During usage, we link the libc_pyjac.so library dynamically to our solver, so OpenFOAM uses the pyJac output of the chemical mechanism we want to use. I implemented a check at the constructor of OpenFOAM side that checks the number of species of the pyJac mechanism linked with the number of species that the user provided via an input file to OpenFOAM by implementing two functions in chem_utils.c of pyJac, PYJAC_NSP() and PYJAC_FWD_RATES():

    if (this->nSpecie_ == PYJAC_NSP())
    {
        Info<<"Mechanism information:\n"<<"Number of species: "<<PYJAC_NSP()<<"\n"
        <<"Number of reactions: "<<PYJAC_FWD_RATES()<<endl;
    }
    else
    {
        FatalErrorIn
        (
            "pyJacLoadBalancedChemistryModel"
        ) 
    }

I can't call NSP and FWD_RATES directly because they are defined as preprocessor directives. I would just return the output from the dummy pyJac output I compiled my model with. At the moment I add these functions to chem_utils.c and chem_utils.h with some bash scripting when I create new pyJac output:

int PYJAC_NSP()
{
    return NSP;
}
int PYJAC_FWD_RATES()
{
    return FWD_RATES;
}

We will be making our source code public and have pyJac-v1 as a dependency. It would be nice if pyJac generated these functions natively when the user installs it as a python submodule via pip (we want users to use it as submodule only, not compile the pyJac from source code). Of course if updating the code and the python submodule is a task you do not have time to spare, I can either try to create a patch for you or simply stick to my bash scripting magic :)

Best,

Bulut

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants