Jump to content

Mr. Heinrich von Zadow

Moderators
  • Content Count

    216
  • Joined

  • Last visited

  • Days Won

    9

Mr. Heinrich von Zadow last won the day on February 12

Mr. Heinrich von Zadow had the most liked content!

Community Reputation

9 Neutral

1 Follower

About Mr. Heinrich von Zadow

  • Rank
    Moderator

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

8348 profile views
  1. 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
  2. Hi Praveen, thanks for the update, much apprechiated. Indeed, surfaces do not propagate their colors, BReps do. Cheers, Heinrich
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. Hi Gian, can you manually run the Allrun script in the design directory? Cheers, Heinrich
  14. 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
  15. 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
×
×
  • Create New...