Jump to content
Mr. Toni Klemm

CAESES System Variables

Recommended Posts

Hi Toni,

 

to get a complete list of variables you can use, enter env() in the console.

 

To get the input dir, use the global command "getInputDir()".

Keep in mind, however, that the correct input dir for a computation is only set while that computation is being prepared. I.e. when you use it as part of a configuration or inside a feature that is triggered from a configuration.

To make it clearer, here's an example:

Enter getInputDir() in the console will lead to the same output as getDesignDir() + "/input":

|> getDesignDir() + "/input"
"C:/Users/bergmanna/AppData/Roaming/friendship/tmp/unnamed.wu8680/manual_results/baseline/input"
|> getInputDir()
"C:/Users/bergmanna/AppData/Roaming/friendship/tmp/unnamed.wu8680/manual_results/baseline/input/"

When you have a feature that includes the line echo(getInputDir()), for example and run it just like that, it will print the same output to the console as above.

 

When you have a configuration with an entry of type FString and set its value to getInputDir(), the entry will have the correct value when running the computation based on that configuration.

The same applies when you, for example, add an entry to the configuration that triggers the feature mentioned above. It will print the correct line to the console.

 

Actually, I think I will add an optional argument of type FExternComputation to the getInputDir() command (similar to the optional FDesign that can be given to the getDesignDir() command). If it is set it will give the input dir for the computation...

 

Arne

Share this post


Link to post
Share on other sites

Hi Arne,

 

env() was excactly what need. Thank you.

 

I write from a feature into the input directory.

Than I need to specify this file as an input file for a computation.

To specify this file independently from the design engine I will now using "$DESIGNDIR/input/*".

 

Toni

Share this post


Link to post
Share on other sites

The DesignDir approach will not work, because the input dir is $DESIGNDIR/$COMPUTATIONDIR/input

 

What I would do in that case is add an FString argument to the feature ("path", for example) and set its value to "getInputDir()" (make sure that the getInputDir() is set as the value of an argument and not called directly inside the feature). Then, make sure that the feature is triggered from the computation's configuration (by adding a "dummy" entry in the definition/configuration that accesses a value from the feature, as I showed at the user's meeting last year, in case you remember).

 

Alternatively, you can pass the computation to the feature and use

string path(getDesignDir() + comp.getName() + "/input")

inside the feature.

 

Note that the second approach will not work, if the feature is used inside the computation's configuration because it would create a circular dependency (the computation would be both, supplier and client, of the feature).

Edited by Mr. Arne Bergmann
Added disclaimer regarding the circular dependency

Share this post


Link to post
Share on other sites

The feature writes a file correctly into ".../baseline/input".

This file should be an input file for a configuration independent of the frameworks file name.

I have to specify this file relatively.

Now I'm using "$WORKINGDIR/manual_results/baseline/input/filename".

This is working.

Share this post


Link to post
Share on other sites

Correct, but since the file is supposed to be the input of a computation, the ".../manual_results/baseline/input" directory is not correct. It needs to be ".../manual_results/baseline/computationname/input" (or, if you only want to run the computation locally, you can even skip the "input" and write to ".../manual_results/baseline/computationname" directly). Otherwise the file will not end up in the computation's working directory.

 

The safest approach is to use the "getInputDir()" command as an argument to the feature and trigger it from the computation's configuration. Doing it like that makes it completely independent of the project name, computation name and the current design (for design engines). See the attached project for an example.

inputDirTest.fdb

Share this post


Link to post
Share on other sites

Hi Arne,

 

thank you for the demonstration file.

This is exactly what I'm doing.

My problem was to specify this file in the Software Connector ;-) as input for a computation.

 

I'm starting the computation, first Feature is running for file output after that in the same computation external mesh generation is starting with this input file.

 

"$WORKINGDIR/manual_results/baseline/input/filename" -> This is what I specify in the software connector.

Do you have a better solution for that?

 

Toni

Share this post


Link to post
Share on other sites

Hi Toni,

 

Actually, with the method I showed in the project, it is not really necessary to specify the file in the SoftwareConnector. Since the feature runs as part of the configuration through the manually added entry, the file will automatically be written in the working directory of the external mesh generation, without the SoftwareConnector "knowing" about it. However, it will still be available for the external program.

 

If you do it "your way" and write it to that intermediate directory in order to be able to specify it in the software connector, it creates performance overhead. First the file is written to the "$WORKINGDIR/manual_results/baseline/input/filename" directory, then the software connector takes that file and copies it to the actual directory. This might be very little overhead, but if the file is large, it could still take some time and create a larger disc usage.

 

I hope this helps.

 

Arne

Share this post


Link to post
Share on other sites

Hi Arne,

 

if I do not specity the file in the software connector it is not transfered into the computation input directory.

It will be only available in "$WORKINGDIR/manual_results/baseline/input".

But in my understanding this should be OK.

 

Toni

Share this post


Link to post
Share on other sites

Hi Toni,

 

Sorry, apparently my answer was not clear enough: If you write the feature like I did (i.e. use the "getInputDir()" as an argument) and link it to the FConfigurationGeneric like I did (i.e. through an extra entry in the definition and configuration)), the file will be written directly into the computation's input directory instead of the "$WORKINGDIR/manual_results/baseline/input" directory. If you do it that way, there is no need to specify the file in the Software Connector and the feature will run and write the file into the computation's input directory for the current design every time you run the computation.

 

 

Let me shortly recap, to see whether I have a misunderstanding:

The file that is supposed to be written by the feature contains your geometry that is supposed to be meshed by the external program. It needs to be kept up-to-date to match the current geometry before running the computation. The file is supposed to end up in the working directory of the computation (well, ok the input directory, but from there it will be transferred to the working directory by CAESES).

We have two approaches. Yours is to write the exported file always in the same location ($WORKINGDIR/manual_results/baseline/input) and then specify it in the SoftwareConnector as an input file in order to get in the right location. In my approach the file is written directly into the computation's input directory because it is linked to the computation's configuration.

 

 

The problem I see with your approach is the following: If you want to run a design engine, you probably want the feature to run before running your computation, so the exported file matches the current geometry, right? So, if you don't set up some kind of dependency between the feature and your computation (through the configuration) the feature will not see a reason to actually run. That could lead to the following behavior:

  • You run the feature in your baseline once, to see that it works. The file now contains the geometry of the baseline.
  • Now you start a design engine
  • CAESES switches into a design, varies the geometry and triggers the evaluations
  • the evaluations trigger the computation, however, since the computation does not know that it needs to run the feature in order to get the current design's geometry in the file, it will just take the existing file containing the baseline's geometry
  • your results will all contain those of the baseline design.

In my approach this risk does not exist, because the computation makes sure (by updating its configuration) that the feature runs before executing the external process.

With your approach you could circumvent that potential problem by adding "myExportFeature.run()" to the preprocessing steps of the DesignEngine, but I think my approach is less error prone, to be honest.

 

Arne

Share this post


Link to post
Share on other sites

For future readers:

 

The misunderstanding was the fact the "getInputDir()" command needs to be set as the value of an argument of the feature, instead of just using it inside the feature. Only that way the correct client/supplier dependencies are built up, so that the feature goes out of date prior to a computation run.

 

If you're interested in details: By setting the "getInputDir()" command as an argument value for the feature, the feature becomes a client of the so-called PathManager, which is the internal object that manages all the paths inside CAESES. That object goes out of date when changing the design (so the correct design directory is used) or when a computation is about to run (to make sure that exports are triggered). So by making the feature depend on the PathManager and making the computation depended on your feature (by triggering it through the computation's configuration), you make sure that your export feature runs prior to executing the computation.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...