Mr. Heinrich von Zadow

Hi there, What do you mean by "seems to ignore it"? If the Design Variables as set to be integers, they should not be set to floating point numbers by the Design Engine. The problematic part will be the handling of such discrete values since SBGO relies on accurate capturing of the entire design space. Perhaps the most effective way could be: 1. Run the DoE and first SBGO with continuous Design Variables 2. Run another SBGO while keeping some Design Variables (those that you need to be at fixed step sizes) fixed --> round them from the optimum of the previous simulation. If you are uncertain if you should go one step up or down (the current best value might sit right in between two steps), or you are unsure of the correlation wrt the objective function: Check the charts and correlations from the initial DoE. If in doubt, just run step 2 multiple times with different fixed values. Typically, with enough initial samples in the result pool, it should take only a few iterations to converge each individual SBGO. I hope this gives you a solid approach to solving your problem. Cheers, Heinrich

Hi there, technically, this can be done in (at least) two ways. 1. You can choose your Design Variable to be an integer and then set up your model such, that it uses a multiple of that integer value times the given step size. 2. Instead of using the default sampling of the SBGO, which is a Latin Hypercube Sampling, you could use a Design Assembler. This is a Design Engine that allows to manually specify the designs to be evaluated. However, I would be very careful with both of these options. Not every optimizer properly handles a mix of discrete and continuous variables and also the training/accuracy of surrogate models might be affected if the training data is not distributed nicely (LHS, Sobol or similar). Cheers, Heinrich

Hi Adrian, but can't you just open the project in CAESES and adjust the boundaries of your LHS sampling algorithm in the GUI? You can then still run the project in batch mode for the generation of the designs... Or do you do the sampling (i.e. LHS) through a method within your python setup? I'm asking, because CAESES does also provide LHS sampling... Also, instead of sampling a large design space and then another one in a second iteration, you could use the adaptive sampling method within CAESES. This will automatically start with a LHS and then switch to an adaptive mode based on uncertainty quantification or other criteria. You can check the documentation for an example on how to run CAESES in batch mode. Cheers Heinrich

Hi Sody, I think one should be careful when using the rand() function in a persistent feature. It seems to remember a fixed seed somehow. If you do not create a persistant feature instance in your project, but rather just transiently execute the definition repeatedly it should behave as expected. Cheers, Heinrich

Hi there, this looks like you are shifting control points too much (or maybe you are shifting them smoothly but accidentally left out a group of points that is just outside the range thereby folding the polygon in an unwanted manner). Try looking at the control polygon to get a better understanding of what went wrong. In addition, I highly recommend to update to the latest release. Cheers, Heinrich

Hi Adam, that looks promising already. When combining everything, you need to distinguish between boolean operations and simply adding sources. I went through your model and corrected a few things -- mostly adding the domain faces one-by-one using individual "add sources" operations. While doing so, I colored each operation so that your inlet/outlet/periodics, etc are colored reliably. I did the same for the blade and extruded and closed it to obtain a closed solid (you don't want any open/red edges and your final BRep should be closed > you can tell it is closed from it's icon being filled with grey color). Then there is only one boolean operation: substracting the closed blade from the closed domain. Since the blade and tip are already colored, the colors will "imprint" onto your domain during that operation. Hope this helps. Cheers, Heinrich FAN4_HvZ.cdbc

Hi Adam, what export format are you using? Can you share the updated project with the BRep you export (you know that you need to select the specific object you are exporting, right?)? Cheers, Heinrich

Hi Adam, take a look at BReps -- they are the way to go when combining, uniting, substracting, etc. various parts of your geometry. For boudary conditions you can make use of colors (their names) which can be applied robustly even when topologiacal changes occur in the model during shape variation. You should be able to find everything to get started within the help menu of CAESES. Cheers, Heinrich

Hi there, a few users have successfully implemented such features with varying degree of complexity. If you are familiar with NAPA definitions you can easily write a custom export in CAESES. However, there is no solution readily available in CAESES. Kind regards, Heinrich

Hi Yuvraj, if everything else is set up correctly, you should be able to abort the CFD run and just take a look at the 'finaldata' file that is written by Dakota. This contains the predicted optimal design (or Pareto set, if multi-objective) and the predicted evaluations. Kind regards, Heinrich

Hi Praveen, thanks for the update, much apprechiated. Indeed, surfaces do not propagate their colors, BReps do. Cheers, Heinrich

Hi Preveen, not sure if the problem still persists on your side? Have you chacked the documentation on boundary coloring/naming in CAESES? It should give plenty of information. Generally, there are no limitations on what colors can be exported ot not (except from export formats that do not support coloring). The name exported will always be the name of the color unless you specify a custom export name for that color. Cheers, Heinrich

Hi Praveen, how did you label/color the subsequent BRep faces? Have you tried to export and import back to CAESES to verify the colors are there? Cheers, Heinrich

Hi Piero, that should definitely work. My best guess is that the problem arises somewhere else in you feature. Could you post the complete Feature definition? Cheers, HEinrich

Hi WX, have you been able to resolve the issue in the meantime? Does it start the allrun script from within CAESES and have you set up any result values or files such that CAESES would know what to look for and when to consider the computation finished? Cheers, Heinrich