Direction of relaxationzones for uniform velocity profile

Hey community,

Is it possible to generate a relaxationzone for a uniform velocity profile that is not parallel with one of the axis x, y or z? To create a 45° angle I tried <direction x="0.70710678" y="0" z="0.70710678" />, but it gives the error "Attribute 'direction' is invalid. missing. Only one axis can be set to non-zero". The xml code in the examples "04RZFlow2D" and "05RZFlowCylinder3D" right after the direction specification is:

                       <_rotateaxis angle="-45" anglesunits="degrees">

                           <point1 x="0.3" y="0" z="0" />

                           <point2 x="0.3" y="1" z="0" />

                       </_rotateaxis>

where these lines do not seem to have an effect on the direction (what are they actually for?).

Do you have any sugestions how to rotate the relaxation zone? My goal is to create a circular velocity field.

Regards,

Hannes

Comments

  • Self fix: I was unaware that the underscore before rotateasis makes the code not count. Rotating the direction of the relaxationzone works as expected.

  • @Hannes I had the exact same issue a while back and was so frustrated to discover it!

    I really think the code should have a warning such as:

    A variable "_rotateaxis" was defined but not used 
    

    Where any variable starting with "_" gets this trigger. Sucks to do a lot of simulations and then uncover that the small setting you changed was actually not changed..

    Kind regards

  • If you write "_rotateaxis" means that you are writing a name of label different to "rotateaxis" so it will not be identified.

  • edited December 2020

    I also tripped in the underscore when dealing with two instructions confusingly working in the same context (see https://forums.dual.sphysics.org/discussion/1818/) Also because in some programming language it is legal to start a name with an underscore.

    However, DSPH does have some directions about using the underscore, although a bit tucked in the documentation. At least I found this first. See in the directory tree doc/xmlformat/FmtXML_Parameters.xml:

    <?xml version="1.0" encoding="UTF-8" ?>

    <!-- *** DualSPHysics (31-07-2020) *** -->

    <!-- *** class: JSph (JSpaceEParms) *** -->

    <!------------------------------------------------------------------------------->

    <!------------------------------------------------------------------------------->

    <!-- *** Example of available execution parameters. *** -->

    <!-- An option can be overridden by commenting on the XML line, using         -->

    <!-- <_parameter... or changing the key value.                                -->

    <execution>

           <parameters>

                   <parameter key="SavePosDouble" value="0" comment="Saves particle position using double precision (default=0)" />

                   <parameter key="Boundary" value="2" comment="Boundary method ...

    Invalidating the key value was another way to override a parameter, for example like this:

    <parameter key="#DtIni" value="0.0001" comment="Initial time step (default=h/speedsound)" units_comment="seconds" />

    The hashes had the advantage that they are used to comment out in Python and Bash, so it's easier to grasp their purpose.

    However, in the most recent XML files, you can compute numerical expressions (great stuff): there you use the hash to mark that the text has to be evaluated as an operation on variables and not as a string (see XML guide). So it is an enabling tag, rather than a disabling one.

    Perhaps, clearing up and bringing these conventions up in the XML guide would be useful at this point (if not done yet; directions welcome).

  • +1

    I have done simulations in the past with #, in which it seemed to me the parameters were actually applied.. Atleast I learned that it did not today!

    I think this indeed should be stated more clearly, since as you describe how it can be confused with the math operations now.

    Ideally there would be a selected list of allowed variables, which would allow the program to output; "A variable named #DtIni was not set." or something like that.

    Kind regards

  • Just to showcase an example where it actually matters to me, and I was not aware that the tag was not applied. I used some gauges to calculate the elevation

    Just now I realized that I did not change my masslimit, since it has a "_" infront of it. I did not spot this at the time unfortunately. Luckily for me it says that the default is 0.4 in 2D, so I suppose that is what it used. If not, I would have to redo my post-processing for 30+ simulations which sucks.

    Kind regards

  • @Asalih3d I don't take the responsibility of the seal, however a default should be what is applied in the absence of a choice of the user's. It is not even a recommended value in itself, although it can be so.

    Looking at the code at https://github.com/DualSPHysics/DualSPHysics/blob/ec025723b947f9d3af96ead3025393681b4fd1ed/src/source/JDsGaugeSystem.cpp#L226

    else if(cmd=="swl"){
      //-Reads masslimit.
      float masslimit=0;
      switch(sxml->CheckElementAttributes(ele,"masslimit","value coef",true,true)){
        case 1:  masslimit=sxml->ReadElementFloat(ele,"masslimit","value");           break;
        case 2:  masslimit=CSP.massfluid*sxml->ReadElementFloat(ele,"masslimit","coef");  break;
        case 0:  masslimit=CSP.massfluid*(CSP.simulate2d? 0.4f: 0.5f);                        break;
      }
    
    

    you stumbled with a soft landing if you are in case 0.

  • The best way to check the parameters that are being applied is to read the those values in the first part of Run.out.... there you can see the values of all parameters that will be used during that execution, which is the most important at the end.

    Regards

Sign In or Register to comment.