Jump to content

Mr. Heinrich von Zadow

Moderators
  • Content Count

    225
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by Mr. Heinrich von Zadow

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. Hi Praveen, thanks for the update, much apprechiated. Indeed, surfaces do not propagate their colors, BReps do. Cheers, Heinrich
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. Dear Yukai, no worries, just had to make sure I understand the problem. If you want to trigger a CFD through CAESES you can either manually run the software connector or perform an optimization which will automatically trigger a CFD evaluation for every design variant. If you want to change the configuration you can change the templates in the software connector (as you described) or modify an input file on your computer to which the software connector refers. Generally speaking you want to use the template approach if you want to modify the input file for each design individually. If the input file is the same for all design variants, it is enough to supply that file to CAESES as a reference. Any changes you make in a CAESES project will be saved (temporarily in a recovery file and permanently once you manually save the project). What I could imagine is, that you changed a parameter for a particular design (i.e. after a design engine run, you can switch into any of the evaluated designs, unlock them and do modifications) -- these changes will not be reflected in the baseline design. Maybe this is what got you puzzled? If you can reproduce the described behavior, I'll gladly take a look to find out whats going wrong. Cheers, Heinrich
  21. Hi YuKai, where exactly do you "modify any parameter in Openfoam"? Do you refer to changes in the template files of the software connector? Any changes in a project that you saved should never change back after re-opening the project. If you arrive at a different state the only reaso I could imagine is that you shoose to recover a crashed file upon opening. In this case, the recovery file and not the project file will be opened which could bring you to a different project status. Best regards, Heinrich
  22. Hi Gian, can you manually run the Allrun script in the design directory? Cheers, Heinrich
  23. Hi YuKai, indeed, this might be a problem with your graphics card. Can you run getGLinfo() in the CAESES console an post the output here? Cheers, Heinrich
  24. Hi there, do you have any specific reason for still using the 4.4.2? I highly recommend updating to the latest release, this alone should give you a significant increase in speed! Cheers, Heinrich
  25. Hi Jan, I don't think there is an option in CAESES to adjust the sensitivity of the zoom. Maybe you can look into the driver/settings of your mouse? Anything else in your setup that might cause the problem (particularly high resolution display, remote desktop, etc)? How does it feel if you hold down ctrl and use the right mouse button while moving the mouse up and down? Cheers, Heinrich
×
×
  • Create New...