boundaryFlags in ProtChBody

[BranocRichards]

On this Branch and case: https://github.com/erdc/air-water-vv/tree/Branoc_2DOWC/2d/floatingStructures/2D_OWC_Chrono

I've been getting a recurring error for over a month where the boundary flags are not being applied properly. The simulations will run properly for a while, and then i'll experience this error again.

Running make distclean and make develop appear to be a temporary fix, but not an ideal one.

Error Log:
Traceback (most recent call last):
File "/home/HR/bri/PROTEUS/proteus//centos/bin/parun", line 6, in
exec(compile(open(file).read(), file, 'exec'))
File "/home/HR/bri/PROTEUS/proteus/scripts/parun", line 449, in
so = proteus.defaults.load_system(args[0][:-3])
File "/home/HR/bri/PROTEUS/proteus/proteus/defaults.py", line 237, in load_system
so = imp.load_source(soModule, os.path.join(path, soModule+".py"))
File "./floating2D_so.py", line 18, in
case = import(name)
File "./floating2D.py", line 601, in
st.assembleDomain(domain)
File "/home/HR/bri/PROTEUS/proteus/proteus/mprans/SpatialTools.py", line 2045, in assembleDomain
assembleAuxiliaryVariables(domain)
File "/home/HR/bri/PROTEUS/proteus/proteus/mprans/SpatialTools.py", line 2099, in assembleAuxiliaryVariables
if not body.boundaryFlags:
AttributeError: 'mbd.CouplingFSI.ProtChBody' object has no attribute 'boundaryFlags'

[tridelat]

@BranocRichards if a simulation starts running with boundaryFlags applied properly, it means that the variable exist and it shouldn't stop working after a while for that same simulation. Same thing if the proteus installation was not modified, the boundaryFlags variable of ProtChBody will not disappear from one case to another as this variable is always declared in cython.

From the information you provided, I think it could be because of one of those cases:

1. you switched to a branch/commit that was before the merge of IBM: coupling with Chrono proteus#949 and built it (then the boundaryFlags variable does not exist on that branch)
2. same as 1), then you switched back to a branch after commit IBM: coupling with Chrono proteus#949 but without building it again (it is a cython module so you need to do make develop again)

[BranocRichards]

OK. as far as I was aware, i wasn't changing branches, but my local master branch (not what i was working on) was sufficiently out of date. All the branches I've used are now up to date with the relevant commit now. I'll keep an eye, but i'll mark this as closed for now.

[BranocRichards]

This has just recurred as of this morning. tried to run two cases with the only difference being wave period, one is giving me the boundary flags error, another is not. These are both on an up to date version of Proteus, as every branch I have worked on is past the commit you mentioned.
I was running cases with no issue yesterday, and have made no changes to the script or proteus since, only changing options from the .pbs script.

[tridelat]

@BranocRichards If boundaryFlags exists in the instance of ProtChBody in one case, there is no reason it would not exist in another case if the ProtChBody instances were created using the same proteus branch/commit, no matter what other unrelated changes are made (such as changing the wavelength in your main file).
I would try running the two cases concurrently to double check, and they should either both fail or both run

[BranocRichards]

@tridelat This is what i did. I submitted the two jobs one after another, the second (if i remember the order correctly) ran, and the first experienced the boundary flag error. I ran more jobs successfully yesterday afternoon, but have had no success this morning, so have run make distclean > make develop

[tridelat]

@BranocRichards By concurrently, I meant submitting them together, using the same Proteus branch, and not changing the branch until they are both running. Or you can submit one after another, but you need to make sure that you do not switch branch in between. It really should not be possible that boundaryFlags exists in one case, but does not exist in another case if you are using the same Proteus branch.