Mr. Heinrich von Zadow

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

Hi Yukai, you can import the csv file via "Import Result Pool" in the optimization workspace to use it as a database for subsequent optimizations. Cheers, Heinrich

Hi Alexis, if you choose to use existing result pools, designs that have been simulated before will not be simulated again. Instead, the old results will be linked. Cheers, Heinrich

Hi Alexis, Sobol+NSGA2: no, unfortunately you cannot re-use the Sobol as first generation of the NSGA2. Constraints: Yes and no... If constraints are such that you can evaluate them before running the external computation (e.g. hard points limiting geometric freedom, geometric properties like cross sectional area, volume, etc.) you can set them at the software connector: This way, no external computation will be run for infeasible designs. If you specify them at the Design Engine, the external computation will run anyways. Sometimes, a mix of both makes sense... Apart from that, in many cases it is possible to set up a geometric model in such a way that constraints are always fulfilled -- this is mostly a matter of clever parametrization and modeling but you can also make use of nested optimizations (e.g. to adjust a free variable automatically in order to fulfill a constraint). Cheers, Heinrich

Hi Alexandros, I'm happy to show you the process, it is pretty straight forward. However, as will any partially parametric modelling, you will need a good baseline geometry if you want to achieve a nice shape variation. In your case, I recommend you to remodel the skeg first. Cheers, Heinrich