Order of Param makes a difference.

[ggruszczynski]

I found that Order of Param in Model makes a difference.
I thought that only Order of <Boxes> in Geometry makes a difference.

My configuration:

./configure --enable-rinside --enable-double --enable-graphics --enable-cpp11 --with-cuda-arch=sm_75 

I was running with GPU SERIAL CUDA

[  ] -------------------------------------------------------------------------
[  ] -  CLB version:       v6.5.0-64-g018acb8b                               -
[  ] -        Model:       d2q9_pf_velocity_CM                               -
[  ] -------------------------------------------------------------------------

https://github.com/ggruszczynski/TCLB/tree/d2q9_pf_cm_p_and_v
(core as in develop)

I was running with:

CLB/d2q9_pf_velocity_CM/main example/multiphase/d2q9_pf_velocity/mrt_dam_break.xml 
CLB/d2q9_pf_velocity_CM/main example/multiphase/d2q9_pf_velocity/cm_dam_break.xml 

In
https://github.com/CFD-GO/TCLB/blob/develop/example/multiphase/d2q9_pf_velocity/mrt_dam_break.xml
https://github.com/CFD-GO/TCLB/blob/develop/example/multiphase/d2q9_pf_velocity/cm_dam_break.xml

Order of Param makes a difference. I get this error:

No water:

<Param name="PhaseField_init" value="1.0" zone="water"/>
<Param name="PhaseField_init" value="0.0"/>

Good:

<Param name="PhaseField_init" value="0.0"/>
<Param name="PhaseField_init" value="1.0" zone="water"/>

[mdzik]

All TCLB XML is write-to-TLCB-as-you-read-XML, so yes - order matters. This is why warnings are displayed in your case (check output) We would need a DOM XML model, not a parser to handle it properly

[mdzik]

To add bit more context:
#100

Without DOM model (build object tree then execute, implement LBM node's claims?) it's not easy to distinguish if a node was written too or not. There is warning in when you write to non-zero value for that case

IMHO One think that could be implemented is that Param without zone MUST always be triggered first, if not fail.
I could do that, but it might be breaking change for some examples. Votes?

BTW: XML standard assures that

<Param name="PhaseField_init" value="0.0"/>
<Param name="PhaseField_init" value="1.0" zone="water"/>

is different from

<Param name="PhaseField_init" value="1.0" zone="water"/>
<Param name="PhaseField_init" value="0.0"/>

Think of it as python's list of dicts. So it's predictable output.

[llaniewski]

"Param without zone MUST always be triggered first" This is not such a bad idea. I vote yes

@TravisMitchell any comments?

[TravisMitchell]

I think a trigger for this is a good idea. If the user is overwriting their zonal value, I think we can assume it is not done on purpose and the code should flag this too them.

Vote: yes

[ggruszczynski]

What is/(shall be) the expected behaviour for the config below?

<Geometry nx="256" ny="256">
	<CM><Box/></CM>
	<None name="lava">Box ny="48" nx="32"/></None>
	<None name="water">Box ny="96" nx="32"/></None>
</Geometry>
<Model>
	<Param name="PhaseField_init" value="0.0"/>
	<Param name="PhaseField_init" value="1.0" zone="water"/>
	<Param name="PhaseField_init" value="-1.0" zone="lava"/>
</Model>

[llaniewski]

@ggruszczynski <Param/> without zone= sets a setting in all the zones. So in your case: first all zones are set to 0, then water to 1 and lava to -1.

I think Michał's suggestion kind of makes sense, that you have to put all the <Param/> without zone= before the ones with zone=, and if you don't TCLB will give an error.