Unable to build

[tillea]

Hi, I tried to build SBML_odeSolver under Debian and was running into the same error as it was reported on the sundials list:

In file included from sbmlsolver/processAST.h:44:0, from arithmeticCompiler.c:46: ./sbmlsolver/odeModel.h:171:3: error: unknown type name ‘CVDenseJacFn’ CVDenseJacFn compiledCVODEJacobianFunction; ^~~~ In file included from sbmlsolver/processAST.h:44:0, from compiler.c:44: ./sbmlsolver/odeModel.h:171:3: error: unknown type name ‘CVDenseJacFn’ CVDenseJacFn compiledCVODEJacobianFunction; ^~~~ ./sbmlsolver/odeModel.h:185:3: error: unknown type name ‘CVDenseJacFnB’ CVDenseJacFnB compiledCVODEAdjointJacobianFunction; ^~~~~ ./sbmlsolver/odeModel.h:187:3: error: unknown type name ‘CVDenseJacFnB’ CVDenseJacFnB current_AdjJAC; ^~~~~

Any clue how to solve this? Kind regards, Andreas.

[raim]

This looks like a wrong version of sundials. Have you checked this? r

On Fri, Jan 27, 2017 at 08:08:04AM -0800, Andreas Tille wrote:

Hi, I tried to build SBML_odeSolver under Debian and was running into the same error as it was reported on the [1]sundials list:

In file included from sbmlsolver/processAST.h:44:0, from arithmeticCompiler.c:46: ./sbmlsolver/odeModel.h:171:3: error: unknown type name ‘CVDenseJacFn’ CVDenseJacFn compiledCVODEJacobianFunction; ^~ In file included from sbmlsolver/processAST.h:44:0, from compiler.c:44: ./sbmlsolver/odeModel.h:171:3: error: unknown type name ‘CVDenseJacFn’ CVDenseJacFn compiledCVODEJacobianFunction; ^~ ./sbmlsolver/odeModel.h:185:3: error: unknown type name ‘CVDenseJacFnB’ CVDenseJacFnB compiledCVODEAdjointJacobianFunction; ^~ ./sbmlsolver/odeModel.h:187:3: error: unknown type name ‘CVDenseJacFnB’ CVDenseJacFnB current_AdjJAC; ^~

Any clue how to solve this? Kind regards, Andreas.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, [2]view it on GitHub, or [3]mute the thread.

References

1. http://sundials.2283335.n4.nabble.com/Building-SBML-odeSOLVER-td4653445.html
2. https://github.com/raim/SBML_odeSolver/issues/3
3. https://github.com/notifications/unsubscribe-auth/AAsjLgoerXYFZ2pQDYjdy6RyCtY1xFBjks5rWhZkgaJpZM4Lv7dH

[tillea]

Hi Rainer,

On Fri, Jan 27, 2017 at 09:27:07AM -0800, Rainer Machne wrote:

This looks like a wrong version of sundials. Have you checked this?

Debian has version 2.5.0 and I was trying to build against this. The sbml-odesolver doc says 2.3.0. Would you think it is possible to upgrade to the latest sundials version in case this might be the cause of the failure?

Kind regards, Andreas.

-- http://fam-tille.de

[tillea]

Hi again, there was another hint for this problem at the Debian Med mailing list:

CVDenseJacFn is declared in cvdense.h from Win32/WinCVODE/sundials/... This file does not look included in ./sbmlsolver/odeModel.h, or perhaps transitively?

An incompatibility between sundials versions is in fact suspected by the writer.

[ghisvail]

Our version is a bit old (2.5.0), at what version is the one vendored in SBML?

[tillea]

Uhmmm, seems we should upgrade sundials first. :-(

[ghisvail]

@tillea I'll try it. I have filed the ITA and successfully did a local build of the latest version. Sounds like it won't be too much work by the look of it.

[raim]

Yeah, SOSlib atm requires Sundials 2.3.0. @tabe has a branch for Sundials 2.4.0, but I don't know whether this worked and whether it implements the full interface to Sundials, including the adjoint sensitivities in CVODES.

[raim]

As a note, releases v2.5.x are not available anymore at the Sundials download site , they only offer v2.4 then v2.6 versions, and the current version is v2.7.

[tillea]

On Fri, Jan 27, 2017 at 01:52:25PM -0800, Rainer Machne wrote:

As a note, releases v2.5.x are not available anymore at the Sundials download site , they only offer v2.4 then v2.6 versions, and the current version is v2.7. We are currently working on a 2.7 upgrade. It turned out that the package maintainers of sundials somehow vanished. I'd recommend to adapt SBML_odeSolver to the latest sundials version (2.7) and we do so in Debian as well.

-- http://fam-tille.de

[raim]

@tabe invested quite some effort to update to Sundials v2.4, so it'd probably best to go from this branch. It would be good to have a rough estimate how much effort it would be to upgrade, whether it would just involve updating function interfaces or more intricate complications should be expected.

[raim]

So I tested @tabe's branch and it compiled well with Sundials 2.7. The programs in the example directory don't work, but the programs in tutorial seem to work (run without error messages). However, the unittest reports 12 failed tests (and 190 checks), so it may still require some effort.

[tabe]

Will take a look at this issue, thanks.

[tabe]

With 0407c496710ac3b106a440bdc27c36cf099a0c29, make check passes without failures on my Debian 8.7 with SUNDIALS 2.7.0.

[raim]

Unfortunately, I still get the same 12 errors from make check after the update; on ancient Ubuntu 12.04. They come from various places, so hard for me to tell, what a common reason could be. Would you have an idea? I will test later today on Fedora F22. It is interesting to note that even test_read_columns fails, which just reads in values from a text/table file.

93%: Checks: 190, Failures: 12, Errors: 0
test_cvodeData.c:80:F:CvodeResults_getTime:test_CvodeResults_getTime:0: Assertion 'CvodeResults_getTime(cr, 0)==0.1' failed: CvodeResults_getTime(cr, 0)==-1717986918, 0.1==1069128089
test_cvodeData.c:136:F:CvodeResults_getSensitivityByNum:test_CvodeResults_getSensitivityByNum:0: Assertion 'CvodeResults_getSensitivityByNum(cr, 1, 2, 3) == .7' failed
test_cvodeData.c:165:F:CvodeResults_getSensitivity:test_CvodeResults_getSensitivity:0: Assertion 'CvodeResults_getSensitivity(cr, vi_y, vi_s, 3) == .8' failed
test_integratorSettings.c:53:F:CvodeSettings_createWithTime:test_CvodeSettings_createWithTime:0: Assertion 'cs->Time == 0.7' failed
test_interpol.c:57:F:read_columns:test_read_columns:0: Assertion 'ts->data[0][1] == 279.88' failed
test_odeConstruct.c:48:F:Model_getValueById:test_Model_getValueById:0: Assertion 'v == 1.5e-15' failed
test_odeSolver.c:198:F:VarySettings_setValue:test_VarySettings_setValue:0: Assertion 'vs->params[0][0] == 7.7' failed
test_odeSolver.c:209:F:VarySettings_getValue:test_VarySettings_getValue:0: Assertion 'd == 7.7' failed
test_odeSolver.c:231:F:VarySettings_setValueByID:test_VarySettings_setValueByID:0: Assertion 'd == 1.2' failed
test_odeSolver.c:252:F:VarySettings_getValueByID:test_VarySettings_getValueByID:0: Assertion 'd == 1.2' failed
test_processAST.c:148:F:evaluateAST:test_evaluateAST:0: Assertion 'fabs((v) - ((log(-1+sqrt(2))))) <= ((double)2.22044604925031308085e-16L)' failed
test_sbmlResults.c:185:F:TimeCourse_getValue:test_TimeCourse_getValue:0: Assertion 'v == 7.77' failed
FAIL: unittest

[tabe]

Which version of libcheck do you use? The avove failures seems to come up only with newer versions of libcheck.

I hope some are fixed by 4e53105803035c6adcb9523103a2efedb252bd2a.

[tillea]

On Mon, Jan 30, 2017 at 02:20:33AM -0800, Takeshi Abe wrote:

Which version of libcheck do you use?

In Debian wie use check 0.10.0.

-- http://fam-tille.de

[raim]

dpkg -l '*check*' says 0.9.8-1.1ubunt. The errors still appear after your update.

[raim]

Ok, I get no errors from make check on Fedora F22 with check 0.10.0. So it all seems fine! Also the command-line tool seems to work, even the old xmgrace and graphviz interfaces work.

I have never merged branches before. There were some commits to the master branch that should probably be integrated with the sundials-2.4.0 branch, then we could change the master to a branch sundials-2.3.0 and promote the current sundials-2.4.0 to master.

[raim]

Before switching master branches, we should tag a release, either 1.6.1 and make the new version 2.0; or, since there was quite some time, but not sure how much functionality increase since 1.6, we could tag the current already as 2.0 and the new sundials upgrade as 2.1. I am not familiar with versioning conventions or good practice. Opinions welcome, I guess @tabe, it is also up to you, since you are responsible for keeping soslib alive and up-to-date!

[tabe]

@raim, sundials-2.4.0 branch has merged master already at 5a8feb9222c5820f5d673c590ca2e474acb41048. It is also very easy to merge it back into master; in fact a fast-forward is enough. I have no particular idea about new version number, so let me follow your suggestion.

[tillea]

I confirm that tagging versions is quite important for users and distributions. A project that does not release new versions will be considered dead - I just realised that the user who pointed me to the software assumed this. I can not give good advise what the "better" versioning sheme (1.6.1 or 2.0) might be but you are well advised to "release often" (by often tagging a state that you want to be used by your useres).

[raim]

Ok, I tagged the current master as release 1.6.1 (added very few release notes), and created a branch sundials-2.3.0 from it (which should have also the more intricate functionality still working; incl. e.g. our internal compiler, and more involved sundials functionality). Please, @tabe, could you merge your branch into master? Then we can give it a new release tag immediately; and we should probably also update README and INSTALL notes wrt Sundials.

[tillea]

On Wed, Feb 01, 2017 at 08:02:05AM -0800, Rainer Machne wrote:

Ok, I tagged the current master as release 1.6.1 (added very few release notes), and created a branch sundials-2.3.0 from it (which should have also the more intricate functionality still working; incl. e.g. our internal compiler, and more involved sundials functionality). Please, @tabe, could you merge your branch into master? Then we can give it a new release tag immediately; and we should probably also update README and INSTALL notes wrt Sundials. Thanks for adding the release tag. I'm waiting for further information about sundials compatibility before I'll keep on working with the packaging.

-- http://fam-tille.de

[tabe]

Merging the branch into master has been done, and INSTALL updated.

[raim]

Ok, great, thanks! I just tagged this release as 1.9.0 now.

[tillea]

On Mon, Feb 06, 2017 at 02:56:17AM -0800, Rainer Machne wrote:

Ok, great, thanks! I just tagged this release as 1.9.0 now. Thanks. I'll let you know in case of further problems, Andreas.

-- http://fam-tille.de