Jump to content

Mr. Heinrich von Zadow

Moderators
  • Content Count

    199
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by Mr. Heinrich von Zadow


  1. Hi Rizuan,

    the important thing to note is, that CAESES itself does not offer any sort of CFD computations. If you want to calculate the total resistance Rt you need to connect CAESES to a CFD solver of your choice through the Software Connector. Which CFD code do you typically use or have licenses available for?

    Best regards,
    Heinrich


  2. Dear Milad,

    If I understand correctly, then yes, that is perfectly normal. The 2000 LHS samples is what you use to train the model. If you'd evaluate your model at these exact points, the prediction would perfectly match the training data (at least for Kriging that is the case). However, the model cannot just predict a pareto front "out of the blue". Usually, what we do is, to run a MOGA (multi objective genetic algorithm) optimization on the model. With large enough populations sizes and number of generations this allows to quickly find pareto-optimal designs (that means that for those designs there is not other designs better in one objective without being worse in an other objective). 

    Best regards,
    Heinrich


  3. Dear Yuwen,

    I'd have to ask a developer to take a look into the code to answer that question. However, I think it might be enough for you to know that the distribution (if not set to be uniform) is dependent on the parametrization of the underlying surface. Hence, by parametrizing the surface differently, you can freely control the distribution of cells.

    Cheers,
    Heinrich

     


  4. Hi Carlos,

    I think I remember these black BReps from the good old CAESES4 days 😉 If I recall correctly this happens when importing IGES/STEP from certain other CAD tools and can be easily resolved by just assigning a different color to the imported parts. Since they are currently black, you would have to use the BRep operation "remove colors" first and then assign a different color...

    Best regards,
    Heinrich 


  5. Hi Alexis,

    the documentation can be searched i.e. for "String" which pops up all the corresponding class functions. You should be able to achieve what you are looking for with the replaceByString command:

    image.png.dae0634250697b852b37d591c5b68c24.png

    The problem with the backslash symbol is, that it is also used as an escape character. Therefore you need to use a little workaround e.g. as follows:

    FString s("a/b")
    s.replaceByString("/","\?")
    s.replaceByString("?","")

    Cheers,
    Heinrich


  6. Hi Milad,

    there is no option to visualize them currently -- we are definitely planning to introduce that at some point though.

    The finaldata file (especially, if you choose a high number of "solutions considered") basically contains the points that lie -- according to the model -- on the pareto frontier. However, the results will definitely be improved a lot if you integrate your calculations into CAESES. The design engine would then automatically verify these candidates and add the new results to the model. This will not just increase the accuracy of the model, but it will do so particularly in the region of interest --> that' why we see such fast convergence with this optimization technique in many cases.

    Cheers,
    Heinrich

     


  7. Hi Milad,

    yes, that's exactly what I did. Is there any particular reason why you are using 4.4?

    If you set up a Dakota Design Engine with the method "Global Optimization on Response" you can choose to use the existing result pool and when you start the Design Engine you can select the table you have just imported. Dakota will then generate a surrogate, run an optimization on it and return the predicted optimum (or multiple pareto-optimal designs in case you have a multi-objective problem and specify "solutions considered" > 1). You can look at the predicted optima in the "finaldata" file in you result directory. 

    The procedure described above is more like a work-around. Usually the idea is, to couple your simulation tool with CAESES and then have the predicted optima evaluated automatically through CAESES. The surrogate model would then be re-generated with the new variants which increases the accuracy of the prediction. The procedure then repeats... 

    Cheers,
    Heinrich


  8. Hi Milad,

    that looks to me as if you have generated these results manually (or through a different tool/script)? Usually, when you set up your design in CAESES and run the simulations through one of the optimization engines, you will have a result table which you can use right away. Alternatively, you could always use Dakota/Surfpack though the command line... In your case, with some changes to the formatting (I did a quick search and replace of \t\t with \t to get rid of the double-tabs), you should be able to import the existing results into CAESES and create a Surrogate aka. Response Surface Model from them. I quickly did that to take a look at the data -- see attached project file. To get a good fitting Surrogate I recommend using a more suitable sampling algorithm (usually Latin Hypercube or Sobol is what we recommend, Adaptive Sampling would be the more advanced option). For the model itself, there are different options available (Kriging works well for most cases I came across recently but depending on your problem you might also want to try out Artificial Neural Networks or Radial Basis Functions...).

    image.png.b2ca06c603c7691ad3b62940a18032c7.png

    For now, the parameters y1 and y2 are just dummies, so they do not return the correct evaluation. However, you can still run an optimization on the existing results and then look into the generated "finaldata1" file to check the predicted optimal designs. As I didn't know better, I specified to minimize y1 and y2 and attached the results. You can easily change that in the Dakota Design Engine.

    image.thumb.png.f501c36040a8444fd741ac1b4a1d1afc.png

    These are the predicted optimal candidates:

    image.thumb.png.2ef04d9ef3970de5a7fa4df08e49a94d.png

    Hope this gives you a good point to start.

    Cheers,
    Heinrich

    importTable.cdb


  9. Hej Ravi,

    I don't think that the Torqeedo props are a standard series. Might be that they use some well known section definitions but I don't think they share these information.

    Designing something that looks roughly like the picture (at least the outlines) will be easy, but you cannot expect to get proper performance this way. What I'd recommend at the very least is, to use a suitable series for the sections (Naca66mod could be a good starting point. Might be that you have to thicken it a little more if you are going for a 3D print), find out the pitch of the original (or, even better the pitch that suits your needs) and then use the propeller sample project that comes with CAESES to adjust chord, skew, pitch etc. distributions along the radius.

    Cheers,
    Heinrich

    • Like 1

  10. Dear Christina,

    what is shown in the video is just an example of parametric geometry modelling. In CAESES you typically define parameters to be used within your model. If you change their values, the geometry is changed as well, depending on how you used them. Parameters can not just hold double values, but also complex expressions (mathematical and also wrt. other objects in your project).

    In addition, any parameter can be turned into a DesignVariable (just select it and click the check box in the object editor). Design Variables can NOT hold expressions, but just doubles (or integers, if specified) and additional lower and upper bounds. The main point here is that Design Variables are the type you use if you want to automatically change their values through a Design Engine (like an optimization algorithm that changes the DVs to modify the geometry to find the optimum shape...)

    Hope this clarifies things a bit for you. You will also find detailed explanations, as well as samples and tutorials in the CAESES documentation.

    Cheers,
    Heinrich


  11. Hi Assiouras,

    it's quite simple: fdb is the file format of the CAESES4.x and older releases, while cdb is the current format of CAESES5.x. There is no backwards compatibility (you can open an fdb in CAESES5 and save it as cdb, but not the other way around), hence the different file type. In addition, anything with an additional "c" indicates a non-commercial license and therefore cannot be opened with a commercial license.

    Best regards,
    Heinrich

    • Upvote 1

  12. Dear Armagan,

    generally speaking, CAESES 5 offers backwards compatibility -- you should be able to open files from CAESES 4, but not the other way around. However, there have been some changes to Feature Definitions and also to the CAD Kernel which might needs some small adjustments in the projects to make it work in CAESES 5. If you can share the project, I could take a look.

    Best regards,
    Heinrich

×
×
  • Create New...