Search the Community

Hi, This is an example of integration with Pointwise and CAESES. First of all create a Glyph file by using Pointwise function "Script -> Begin to Journaling". Use your your Glyph file (e.g. roPaxLowerBulbScript.glf) as argument for the computation. The leading -b starts Pointwise in batch mode. Best regards, Takamichi Hiroi roPaxLowerBulb.fdb

Hi everybody, I recently tried my hands on integrating CAESES with fluent and i think its worth sharing for those who work with fluent and will like to use CAESES parametric models. Please find attached a copy of my project file. its a simple meta-surface elbow i designed with an ellipse curve.Functions for the "width and "height" of the curve are defined. you can have a look at how parameters are set from function curves. I used ICEMCFD as my meshing tool and Fluent as CFD solver. specific files such as the *.rpl and *.jou were used as input files( checkout the attachments). Absolute paths should be changed to relative paths via "getdesigndir()...." (not all paths are necessary!). A *.bat file, RunFluent.bat, was used to run both ICEMCFD and Fluent in batch mode. Snapshots, graphs etc from fluent can be included as results files for post processing. Details on post processing can be found in CAESES tutorials " getting started". You can have a look. Suggestions are welcome. Best regards, Richard "N.B: CAESES is one of the most powerful softwares for tight integration with CFD softwares for DoE and Optimization. All you need to know is to understand how your External CFD software handles its files to know exactly which input and result files to use. it must also have the capability of running in batch mode." Project1_elbow.fdbc

The attached project shows the export feature I presented at this year's User's Meeting. Its purpose is to show how to use Features to export and import custom file formats using Features. Additionally, it shows how to connect such an export to a SoftwareConnector. [update 4.0]: Please read the second post in this topic to see the improvements regarding connecting your export feature with the Software connector. The geometry is based on the "Basic Hull Model" sample. There are two FStructPanelMeshes (main and stem) that are grouped in a FPanelMeshGroup and transformed using the combination of FImagePanelMeshGroup and FScaling. Running the Feature "exporter" will export the scaled PanelMeshes to a file (see the console output for the full path). The Feature "importer" will import files of the correct format (e.g. one that was exported using the "exporter") to structured panel meshes. The "success" value that is calculated in the export Feature is added to the configuration of a SoftwareConnector, so that it is ran prior to running the external computation. [update]: In 4.0 this is no longer necessary (see next post). Notes: The export feature is written to be used within a SoftwareConnector. In order to make sure that the feature is triggered before running the computation, it takes the file path as an argument with the value set to "getInputDir()". That command yields the input directory of the currently running computation. By setting that command as an argument value, the feature becomes dependent (i.e. a "client") of the so-called PathManager. This ensures, that the export will be triggered before running a computation. If you execute the feature outside of the computation-run the exported file will not be in the correct location for your external program. [update]: In 4.0 this is no longer necessary (see next post). Using "getInputDir()" instead of "getResultsDir()" (which gets the actual working directory of the external process) will export the file to the "input" sub-directory of the computation's results directory. This is done in order to allow the feature to be used in conjunction with remote executions of computations using the SshResourceManager. [update]: In 4.0 this is no longer necessary, files referenced with a relative path are automatically written into the input directory (see next post). featureExport.fdb

Hi everyone, I coupled CAESES and Starccm+. I'm trying a cycle out. As you can see on screenshot, it says n/a for "eval_coeff"; but when i click on created design, i can see the value on the left side. It does not count in the "eval_coeff" value when making evaluation. How can I overcome this problem? Any idea?

Hi together, Please note that CAESES can be utilized as an OpenFOAM GUI (Graphical User Interface). There are free academic versions of the CAESES pro edition for students and PhD students as well as trial licenses with flexible time frames. There are also special editions for small companies, start-ups and freelancers. Compared to other tools in the market, CAESES is good at automation, i.e. if you already have an existing OpenFOAM setup and you want to analyze design variants of your product, then CAESES might be a perfect choice. Especially, if geometry variation plays a major role. In contrast to that, a tool such as HELYX-OS might be a better choice e.g. if you would like to set up an OpenFOAM case from scratch. Here are some CAESES-specific offers: Conveniently configure and manipulate template files (e.g. controlDict or any other ASCII file) in the GUIChange your geometry design and trigger OpenFOAM with a single mouse-click for analysis (i.e. streamline your design process / automation)Use your individual result values such as pressure loss or homogeneity for an objective function in design studies and shape optimizationsPostprocess your simulation data (streamlines, contour plots etc) Here is a video that shows some of the features in CAESES. Cheers Joerg LAST UPDATE FEBRUARY 2018

When using an external program with CAESES, there is one major requirement to that program: Once the executable is finished, all result files need to exist. This is true no matter whether the external software is called directly as a local application or through the SshResourceManager as a remote application. Why is that so? CAESES needs to know when the external program is done writing its results, in order to be able to read in those results. So, what it does is to assume that once the executable that was called returns, all results are available. What does that mean for me? In general you can safely assume that a program's executable will not return until the actual process is finished. However, there are some exceptions to that rule. One example for such a behavior (although it is highly unlikely that it will be used from within CAESES) is Firefox. Only the first instance of Firefox will behave in the required way. When starting a second instance of Firefox, the process will return right away, as it uses the original Firefox process to run. Another example that is a lot more likely to be used from within CAESES is when trying to execute an external program through a grid engine, for example the Oracle Grid Engine (formerly Sun Grid Engine). In general, submitting jobs (i.e. requests to run a certain program) to a grid engine through a program like qsub is a non-blocking process. The job is added to the waiting queue of the grid engine and the submitting program will return right away. Additional tools (e.g. qstat) can then be used to monitor the state of the job. However, when using qsub or a similar program as the executable in CAESES, it will be recognized that the executable has returned and assumed that all result files are present, which is not the case. In the example of the Oracle Grid Engine there is a way to tell qsub that it should not return until the job has finished. That execution mode is done by providing the "sync y" option to qsub (either on the command line or in the configuration file). Note that the Sun Grid Engine must be configured to allow blocking jobs (i.e. must allow to use the "sync y" option). How can I find out if my executable is affected? Well, if you never experience the problem that CAESES complains about result files not being there, although they are when you look in the file browser, or that a computation finished although you know that the external program is still running, you don't need to worry about it. If, however, you do experience one of those two problems, or are planning to use a grid engine like the Oracle Grid Engine, you can do the following to ensure that the described problem does no affect you: Run the program from a terminal (cmd.exe on Windows). If the terminal returns to the command prompt right away although the program continues to run, you have identified the problem. As the Firefox example shows, even if it does not return right away, you may have to double check by starting a second instance of the program through another terminal. If you have identified, that your external program indeed shows this behavior and is the problem why your integration does not work, one way to solve the problem, is to wrap the call to the executable in a shell script that stores the process ID of the started exectuable in a variable and periodically looks whether the PID still exists. Once it does not exist anymore, the shell script should exit. An alternative to a shell script would be to write a simple program using your favorite programming or scripting language.