raven_framework interfaceCheck error

[jchen56]

---

Issue Description

What did you expect to see happen?

Using the following command line to do interface check:

raven_framework inputFile.xml interfaceCheck

Supposed to see if the interface is functional without invoking the executables.

What did you see instead?

IOError: There were failed runs; aborting RAVEN

It seems that RAVEN submits the jobs, ignoring the keyword interfaceCheck.

Do you have a suggested fix for the development team?

A workaround suggested is using:

python ../../../../framework/Driver.py inputFile.xml interfaceCheck

In this way RAVEN recognizes the keyword and tests the interface without invoking the executables of the codes linked by the interface.

Suggestion would be checking the argument processing in the raven_framework.

Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

The input files are from the tests in the codes. Location is:

~/raven/tests/framework/CodeInterfaceTests/Scale/

---

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or improvement?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users. no impact on the results.
• 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

---

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.) This is a defect in the test system, not the raven framework, we may need to test our test system in the future
• 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
• 4. If the issue is a defect, does it impact the latest stable branch? If yes, is there any issue tagged with stable (create if needed)?
• 5. If the issue is being closed without a merge request, has an explanation of why it is being closed been provided?

[PaulTalbot-INL]

Out of curiosity, what is the branch (and date of last commit) that you're working with when you see this?

[jchen56]

Actually I haven't created a branch but I'm working with Andrea on the interface between RAVEN and SCALE. I did a git pull just before I ran the above tests, so I assume the code is up to date.

[alfoa]

@PaulTalbot-INL yes it is in devel...i checked it

[PaulTalbot-INL]

I just tried the same thing on (current) devel and I did see failed runs.

Oddly, there is code in raven_framework to preserve the arguments in the $ARGS variable.

[wangcj05]

We have an open issue for that, see #440. I'm not sure if this is fixed or not. At that time, if you run run_tests with interfaceCheck, the code will work, and if you run raven_framework, the code will ignore the key word. Hopefully, this will help.

…

On Mon, May 21, 2018 at 2:27 PM, Paul Talbot ***@***.***> wrote: I just tried the same thing on (current) devel and it passed for me on the melcor interface ... and I checked and we do preserve arguments in the raven_framework call. My command was: ~/projects/raven/raven_framework test_melcor_interface.xml interfaceCheck — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_idaholab_raven_issues_659-23issuecomment-2D390772011&d=DwMFaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=vJsbMjnzR6ErmdvVqv2kNhwbKhk1o91w6B8VQ4EHCto&m=AJMwNGMig3Ijri2gl45bOqGSRozXfJjD5QcldVLfuTg&s=2ipKxd4ovOktXhI5OKXI6L2aALLZ4vtauBJgVC2Ny-M&e=>, or mute the thread <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AG-2D1714DE-5FCbkSW8RiRd34Iayx3DJLKDks5t0yMbgaJpZM4UHgRc&d=DwMFaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=vJsbMjnzR6ErmdvVqv2kNhwbKhk1o91w6B8VQ4EHCto&m=AJMwNGMig3Ijri2gl45bOqGSRozXfJjD5QcldVLfuTg&s=Hj8Gsv2CAG8wo6rYM2Di8elfSPXI9g5krIewbNyCRQQ&e=> .

-- Sincerely, Congjian Wang PhD, Nuclear Engineering Methods Development, INL 2525 North Fremont Ave., Idaho Falls, ID 83415-3860 Work Phone: 208-526-7220

[PaulTalbot-INL]

I found the fix.

When listing the arguments to the python call, in bash you have to use ${ARGS[@]} not $ARGS or it only passes through the first entry. Kind of like our PointSets, actually...

I'll have a PR for this shortly.

[alfoa]

Closure checklist passed...

No email is required since the defect was affecting a "testing" feature that we currently do not expose to the users