Errors reading *.eqn file in version 3.0

[jnavarla]

Hi all,
I'm using KPP to develop an Ultrasound driven chemical reaction and I generated the model in KPP v2.2.
I have updated to KPP v3.0, but I have errors reading the *.eqn file looking for a 'none.def' file which is no defined.
I have reviewed all the files, but I cannot seek any difference when I process the files with v2.2.
Is there any care/suggestion for the eqn files in the new KPP version?
I attach a copy of *.eqn file
aquMTv2.eqn.txt

Thanks in advance for any suggestion.

Javier

[yantosca]

@jnavarla, thanks for writing. Can you also post any other files like *.kpp and *.spc? I will try to replicate the issue.

[RolfSander]

none.def used to be an empty dummy file. Do you have something like

#INTEGRATOR none

in your code?

[jnavarla]

@jnavarla, thanks for writing. Can you also post any other files like *.kpp and *.spc? I will try to replicate the issue.

Thanks. Yes, here you have the kpp and spc files
aquMTv2.kpp.txt
aquMTv2.spc.txt

[jnavarla]

@jnavarla, thanks for writing. Can you also post any other files like *.kpp and *.spc? I will try to replicate the issue.

Thanks. Yes, here you have the kpp and spc files aquMTv2.kpp.txt aquMTv2.spc.txt

none.def used to be an empty dummy file. Do you have something like

#INTEGRATOR none

in your code?

Hello Rolf,
Yes, I have this line in *.kpp file. Should I remove it?
Regards,
Javier

[RolfSander]

Yes, it should be removed.

However, I wonder which integrator are you using, and where have you defined it?

[yantosca]

I was able to get KPP to work with:

#INTEGRATOR     rosenbrock
#LANGUAGE	C
#DRIVER		general
#JACOBIAN	SPARSE_LU_ROW
#HESSIAN	on
#STOICMAT	on
#FUNCTION	AGGREGATE
#DOUBLE	        ON

#include aquMTv2.spc
#include aquMTv2.eqn

I believe that when you specify the #MODEL keyword, KPP looks for a *.def file, as described in the documentation.

[yantosca]

I was able to get KPP to work with:

#INTEGRATOR     rosenbrock
#LANGUAGE	C
#DRIVER		general
#JACOBIAN	SPARSE_LU_ROW
#HESSIAN	on
#STOICMAT	on
#FUNCTION	AGGREGATE
#DOUBLE	        ON

#include aqu.spc
#include aqu.eqn

I believe that when you specify the #MODEL keyword, KPP looks for a *.def file, as described in the documentation.

[RolfSander]

@yantosca: Maybe we should mention this in the box of our documentation at:
https://kpp.readthedocs.io/en/stable/getting_started/00_revision_history.html#kpp-3-0-0

Something like:

The dummy integrator "none" does not exist anymore. Thus, commands like

#INTEGRATOR none

should be removed.

[yantosca]

@RolfSander, I'll work on that. Thanks!

[RolfSander]

Thx, @yantosca !

[jnavarla]

Yes, it should be removed.

However, I wonder which integrator are you using, and where have you defined it?

I'm using Rosenbrock.m defined in $KPP_HOME/int. Now, removing #INTEGRATOR none , KPP works with my *.eqn files and generates the matlab code, but it gives errors when running. Maybe some call is written in a different way in version 3.0 and gives the error in matlab; I'm running R2021a. I will check the generated matlab code to look at.
Thank you very much for your help @RolfSander
Javier

[jnavarla]

I was able to get KPP to work with:

#INTEGRATOR     rosenbrock
#LANGUAGE	C
#DRIVER		general
#JACOBIAN	SPARSE_LU_ROW
#HESSIAN	on
#STOICMAT	on
#FUNCTION	AGGREGATE
#DOUBLE	        ON

#include aqu.spc
#include aqu.eqn

I believe that when you specify the #MODEL keyword, KPP looks for a *.def file, as described in the documentation.

Thank you @yantosca for your reply. Yes, I'm using a *.def file (attached here), but the problem was on #INTEGRATOR command as @RolfSander suggested.
The C or Fortran compilation always is possible but I would like to compile in Matlab just to use the graphical interface.
This is my *.def file.
aquMTv2.def.txt

The matlab code gererated with kpp v2.2.3 works without problems, but the code generated with kpp v3.0.1 doens't.
I will check where is the difference on the generated codes.
Thank you, again
Javier

[RolfSander]

Sorry but I'm still trying to understand your code...

You say that you are using Rosenbrock.m. This means that somewhere you
must have these statements:

#INTEGRATOR rosenbrock
#LANGUAGE	matlab

However, I cannot find these lines anywhere in the code that you have
provided. Is there another KPP file that you are using?

[jnavarla]

Sorry but I'm still trying to understand your code...

You say that you are using Rosenbrock.m. This means that somewhere you must have these statements:

#INTEGRATOR rosenbrock
#LANGUAGE	matlab

However, I cannot find these lines anywhere in the code that you have provided. Is there another KPP file that you are using?

Sorry @RolfSander and @yantosca . I realized that I send you a wrong *.kpp file. I'm sorry to waste your time.
Here you have the kpp file I'm using.
aquMTv2.kpp.txt

Instead #INTEGRATOR rosenbrock, I'm using a #DRIVER rosendrv,
with the driver:

rosendrv.m.txt

With these files I can have a matlab code but I have execution errors related to Aout
"Output argument "Aout" (and maybe others) not assigned during call to "aquMTv2_Fun".

I read something about this problem in another matlab thread here and I will check that later.
Thank you very much for your help.
Javier

[yantosca]

Thanks @jnavarla. In KPP 3.0.0 we added Aout as an argument so as to get the reaction rates out for diagnostics (if so desired). Also @RolfSander and I have mostly worked with the F90 and C interfaces but not with matlab, so there may still be a few issues. We had @jenniethompson and her group help us out with the matlab version for 3.0.0.

[RolfSander]

Thanks @jnavarla, now I understand how you create the matlab code.

It is possible that this is a matlab-specific problem related to Aout. There is already another issue here (#56) in which we discuss the problem. I thought that we had already solved it, but maybe there is still some bug.

[jnavarla]

Thanks @jnavarla, now I understand how you create the matlab code.

It is possible that this is a matlab-specific problem related to Aout. There is already another issue here (#56) in which we discuss the problem. I thought that we had already solved it, but maybe there is still some bug.

Thanks @RolfSander . Yes, the problem in *_Fun.m generation still persist in kpp v3.0.1. As it is explained in #56 the arguments in the function call are wrong.
But, using the *_Fun.m subroutine generated by kpp v2.2.3, the matlab code works.
Best regards,

[RolfSander]

Does it work if you copy the matlab files from the old KPP version into KPP-3.0.0?

As @yantosca already mentioned, we are not actively using matlab. However, if you let us know what works for you, we can update the matlab files accordingly for the next KPP release...

[jnavarla]

Does it work if you copy the matlab files from the old KPP version into KPP-3.0.0?

As @yantosca already mentioned, we are not actively using matlab. However, if you let us know what works for you, we can update the matlab files accordingly for the next KPP release...

Yes, if you copy the ROOT_Fun.m matlab file generated from a previous version ok kpp, for instance in my case v2.2.3, changing the file generated by v3.0.1, the matlab code works properly without execution errors. I've tested this with my model, but the small_strato.* either. This model is small and it is easy to check the rate equations by hand. Both functions generate the same individual reaction rate terms and the time derivative of the state variables of the system (Vdot),
Regards,

[RolfSander]

Great to see that it works for you if you use ROOT_Fun.m from v2.2.3. Still, it would be nice to solve this problem in a better way. Could you post the diff between both ROOT_Fun.m files? That should give us a hint...

[yantosca]

@jimmielin had posted this issue #56 about issues with Fun in matlab. Not sure if this is why the behavior was changed in KPP 3.0.0.

[jnavarla]

@jimmielin had posted this issue #56 about issues with Fun in matlab. Not sure if this is why the behavior was changed in KPP 3.0.0.
Hello Bob,
Yes, this is the same issue as @RolfSander suggested me.

[yantosca]

@RolfSander @jnavarla @jimmielin: Wondering if we can close out this issue. I believe #99 may have addressed this.

[RolfSander]

@yantosca: Thx for taking care of those old issues. Yes, I think we can close this one.

[yantosca]

Closing this issue. Thanks @RolfSander