Systemtest nutils-OpenFOAM fails

[Eder-K]

Lately, the nutils-of test is crashing due to an error in the nutils participant:

nutils-adapter            | Traceback (most recent call last):
nutils-adapter            |   File "cht.py", line 132, in <module>
nutils-adapter            |     nutils.cli.run(main)
nutils-adapter            | AttributeError: module 'nutils' has no attribute 'cli'

whereby the error refers to the develop version of cht.py.

Notably, the systemtest currently always uses the newest version of nutils, and the first occurence of the error coincides with the release of nutils v6 and development start of nutils v7.

Related issue on systemtests: precice/systemtests#219

[uekerman]

How to update: http://www.nutils.org/en/latest/changelog/

[Eder-K]

This has been resolved by keeping the nutils version static at v6.0, see precice/systemtests#218.

[uekerman]

I run locally with the newest Nutils dev version and can no longer reproduce that problem. Could we switch the systemtests back to use the dev version of Nutils? This will allow us to catch problems early on again.
@Eder-K @MakisH

[MakisH]

I see two needs:

• Knowing if a change in the adapter (or preCICE) broke something
• Knowing if a change in Nutils will break something

For all of our tests we currently apply the first option. In OpenFOAM, for example, we test with OpenFOAM 5, but I often try the adapter with upcoming versions, to see what will break.

I know that the Nutils adapter currently does not change almost at all, so we could treat it differently. However, I wouldn't like to know that some tests use different assumptions than others and I guess that eventually we will have changes/additions.

I would prefer that we keep the test with a fixed Nutils version, but we also add another test with the develop branch (pottentially as "allowed to fail"). This way, the next time a test fails, we will immediately know why.

[uekerman]

I would prefer that we keep the test with a fixed Nutils version, but we also add another test with the develop branch (pottentially as "allowed to fail"). This way, the next time a test fails, we will immediately know why.

sounds good to me 👍

[IshaanDesai]

No longer relevant as a restructuring of the system tests is planned in the near future.