Bug report: Compilation failure when multiple nimbleFunctionList objects share a nimbleFunctionVirtual class definition.

[David Pleydell]

Hi 

I am encountering compilation errors when multiple nimbleFunctionLists share the same "contains" argument within a single setup function.  If I duplicate the nimbleFunctionVirtual code and create multiple names for essentially the same thing then my code compiles and runs as expected. If I remove the apparently redundant calls to nimbleFunctionVirtual my code will not compile.  My understanding (based on section 15.4.8 of the manual) is that the call to nimbleFunctionVirtual creates a class definition, so it does not make sense to me that two nimbleFunctionLists should not be able to share the same class definition.  

My operating system is Ubuntu 18.04.3 LTS (Bionic Beaver).

I attach some code that compiles and runs fine as it is. To obtain the compiler error simply search for all instances of "Out2" and replace with "Out".  This results in the function lists "getState" and "getDeriv" sharing the same class definition (classVoidInDouble0Out) and the compiler does not accept that.

There are more explanations of what my code actually does in the header of the attached file. Please also let me know if you think the algorithm I've developed here is worthy of incorporation into nimble, or would be better released as a separate package.

If this is not a bug in nimble then a clearer error message would be a very valuable development.  The error message says "duplicate symbol name: getState", so I checked many times and found no duplication of getState. The problem was that I was using classVoidInDouble0Out multiple times, so an error message pointing to illegal recycling of classVoidInDouble0Out (and not getState) would have really helped.  It took me several days of blind stumbling before I hit on the Out2 solution. 

Many thanks for continuing the nimble development. It's really a great tool! 

All the best 

David

[David Pleydell]

Here's a new version of the script containing an unrelated bug fix (required for correct algorithm behaviour when intermediate nodes are placed between state and rate nodes).

The compilation bug is unaffected by this minor change and the previously provided details remain unchanged. 

Best regards

David

[Perry de Valpine]

Hi David,

Thanks for this bug report.  It will take some time for me to dig into this.

-Perry

--
You received this message because you are subscribed to the Google Groups "nimble-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nimble-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nimble-users/dbce38d2-a731-4d40-b4aa-0ec06720b8a8%40googlegroups.com.

[Rui Martins]

Hi all,

while trying to fit some models I made a simple mistake:
I defined 100 000 iterations and 500 000 burn in samples instead of 50 000.
It took a while to figure out why nimble was freezing and in the end it was a simple additional 0  in the burn in.
Is it possible to add a warning to nimble and stop the computation when nburnin > niter ?
Because when this happens nimble freezes.

thanks
Rui

[Daniel Turek]

Interestingly, this exact issue was raised to the nimble team not long ago by another user.  You're right, there was no checking for this case, and it could lead to a crashing of compiled execution.  In response, I added a check and a friendly error message, for exactly that case when (nburnin > niter).  This fix is already available on the development branch of nimble (on github, branch "devel"), and will be included as part of the next updated nimble package release.

Thanks for the comment and helpful feedback, Rui.

Daniel

--
You received this message because you are subscribed to the Google Groups "nimble-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nimble-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nimble-users/714908081.101244.1582619732261%40mail.yahoo.com.