Hello CalculiX users,
at the moment I’m devoloping a python wrapper for generating ccx input files, where each keyword (i.e. *STEP) is represented by a class. Each class takes the parameters and data the keyword needs and provides a method to return the keyword string.
So a ccx model can be build with a list of python objects.
Here comes my question, because the ccx manual is a bit unclear about this point:
Some of the keywords have boolean-like parameters i.e. NLGEOM in *STEP or SMALL SLIDING in *CONTACT PAIR.
What is the correct syntax to switch them on and off?
So far I have seen 3 different possibilities in the docs:
- List Parameter without value → ON,
skip → OFF or default
- PARAMETER=YES → ON,
PARAMETER=NO → OFF
- PARAMETER=ON → ON,
PARAMETER=OFF → OFF
Is there a universal way to treat this boolean-like parameters so it will work for all keywords?
In my code I wanted to be as explicit as possible. My prefered mapping would be:
Python variable → keyword-string
parameter = None → skip (ccx default)
parameter = True → “PARAMETER=YES”
parameter = False → “PARAMETER=NO”
Will this work for all keywords?
For everyone who is interested in my work, I will make it open source as soon as it has reached a considerable mile stone.
To keep it consistent and clear, I would stick with PARAMETER=YES or PARAMETER=NO. It should work in all the cases but it would be better to test it. For example, the NLGEOM parameter is normally either omitted or placed without a value but it will also work if you use NLGEOM=NO (same as omitted) or NLGEOM=YES (same as placed without a value).
Hello Calc_em, thank you for your answer and for sharing my opinion about setting the parameters to Yes or No explicitly.
Of course, testing would be the best way, but it’s a lot of work to set up tests for every boolean parameter in every keyword. So I was hoping that anyone (maybe one of the developers) can confirm my approach and I can avoid all the tests.
That sounds like a good generally useful project. I think something similar already exists (pycalculix?) but it’s probably easier to start from scratch instead of trying to work on somebody else’s code.
I’ve implemented a CCX input file generator too and I can understand the desire for consistency, but I just followed the manual and don’t like to rely on undocumented behavior.
Sometimes I also referred to the Abaqus manual and tried to favor whatever was common between them. I think the names of shell and membrane element faces also have several choices but not the same set as Abaqus.
Looking at the code, it seems ad-hoc, for example, in steps.f:
& (textpart(i)(7:9).ne.'=NO')) then
that looks like =YES and =NO would both mean yes.
Thank you vicmw for your usefull answer. This proves my approach wrong. So i will stick to the manual und decide for each keyword individually how to treat boolean parameters.