Help for Beginners

[Help for Beginners]

Hi Chris,

 

alright, here we go:

 

A: of course, the coons patches have an angle at the waterline since there is no tangent inforamtion passed from one surface to the other. A simple solution to smooth this area out would be to trim both surfaces and add a fillet surface in between. As those pictures show:

 

 

B: You had the xPos curve wrong. This should be a straight line running at 45° - it simply means, that the curve engine looks up the z-value a every x-position of this curve and then uses this z-value as x-Position for the current section...

 

In this case, there will be a discontinuity between the main hull and the bow, since the main hull has a sharp knuckle at x=31,8 m so you can't just connect a rounded section... When using the CoonsPatches, you can avoid the problem by not making the fillet to wide. You could even think about widening it towards the stem if need be...

 

The resulting hull from trimming and filleting the CoonsPatches looks good to me so I will leave 1 and 2 for you to figure out by yourself if you are still interested ;)

 

 

Cheers,

Heinrich

boat_7.fdbc

[Help for Beginners]

Hi Chris,

 

If you really want to use a metasurface in this case, I would recommend you to create the sections for the curve engine at constant z so that they rather represent waterlines than actual sections. This way you can easily extract the tangent from the adjacent surface, set an entry angle at the bow and match your given waterline and deck shape. You will probably get nice results with an FSpline or alternatively a BSpline/NURBS curve based on 4 control points.

 

However, if you just want to have a bit more control over the flare in the bow region, why don't you just parameterize the waterline and deck curves? This should give you plenty of control... If you go back to my first post you will find a good starting point for parameterizing the curves - I recommend you combine those projects into one to have a robust parametrization of the design curves along with the meta surface for the main hull portion and the coons patches (or alternatively another metasurface) for the bow.

 

BTW: You seem to use the FSpline as a straight line in many places throughout the project - you might want to check out the corresponding tutorial as it is a far more powerful curve than that and especially valuable in hull design!

 

Regarding the section at the transom: The hull surface simply does not reach all the way back to -1.7. If you create your first section a -1.6999 the section is cut correctly...

 

One more question: what are all those sections in 'NEW_SECTIONS' for and why do you create them manually?

 

 

Best regards,

Heinrich

[Help for Beginners]

Hi Chris,

 

I will take a look and try to answer your questions.

@ Mrs. Gusain: Please try to work through a few tutorials first as most basic questions should be answered there pretty well. Take a closer look especially at the new CAESES Help in the Documentation Browser under category Graphical User Interface / Object Visibility.

[Help for Beginners]

Good morning Chris,

 

Let me answer your questions: with 1 and 2 you are absolutely right, so 3:

 

It is more a leftover from me playing around. You can probably delete the surfaces and use trimmed image curves for the coons patch instead (see next answer about the image curves ).The tangent information of adjacent surfaces is only taken into account when all 4 sides of the coons patch are surface curves (such as edge, iso-parameter curves, etc... identified by the red curve icon)

 

4. I used image curves because I allows me to easily trim them to the right length (by setting the domain start and end). For the lower bow surface I created an imagecurve c1 of |NEW_SECTIONS|CPC_1. This one I trimmed such that it starts at the same x where the waterline starts (31.8m). Afterwards I created another image and trimmed it at z=0.01 (to make sure it ends just where the radius of the stem starts). I did this in two steps, because the original |NEW_SECTIONS|CPC_1 has two intersections with z=0.01 and by trimming at x=31.8 first I make sure I get the right intersection...

This has nothing to do with continuity, it is just about creating the boundary curves for the coons patches.

 

5. Yes it is just a very convenient way to close the hull by extruding all the open edges to a certain plane. You can use this on any BRep with open edges. Simply create a BRep , then add sources (in our case the 3 seperate surfaces that make up the hull) and then add another operation (click the green plus button 'add new operation' in the object editor with the BRep selected) - choose extrude edges to plane, define a plane, elevation and if you want to close the extrusion and finally TOGGLE the small checkbox next to the newly created operation to activate it.

 

6. For quick section visualization you can use the display options at the very bottom of the object editor of surfaces, Breps etc. Simply activate the different planes to draw waterlines, sections and buttocks and put in a series of the form: start,end:number

You should have this parameterized to make it work even when the hull changes.

 

Make sure to also play around with the section filters - together with x/y/z view this gives a nice view on the hull in section mode...

 

 

and 7 (from your newest post): I guess the main difference are the different surface types, but also like I showed to you earlier parametrization of the curves matters a LOT and can be often times used to tweak the shape of the hull.

 

Wish you further good progress!

Cheers,

Heinrich

 

[Help for Beginners]

Hi Chris,

 

sure, take your time!

 

Cheers,

Heinrich

[Help for Beginners]

Hi Cris,

 

just saw your previous post - of course you can also use ruled or developable surfaces as I proposed earlier instead of the metaSurface - for the bow I would suggest using the coons patch approach I have shown. Note that the coons patches actually take into account the derivatives of adjacent surfaces if they are fed with surface curves (e.g. edges...) - this makes it very easy to achieve a smooth hull!

 

About the waterlines: From what I can see, if you change the draft to say 3m, your waterline moves up as expected on the aft end. However, for the forward end the underlying curve does not reach an elevation of 3 and also the draft is not linked.

 

You should use a polycurve cPoly from c4 and c1 and then cPoly.fv(2,PARAMETERS|Draft) - see the attachment. However, my earlier file is probably already far more advanced so you might want to bring everything together...

 

Cheers,

Heinrich

boat_3.fdbc

[Help for Beginners]

Hi Chris,

 

I am not sure I really understand what you mean by editing the imported Nurbs curves. It might be that you are referring to partial parametric modelling techniques such as transformations and free form deformations to allow form variation. In that case image surfaces are what you are looking for, but you can apply those transformations (e.g. Lackenby shift) also further downstream to e.g. a BRep of the complete hull...

About the surfaces you should definitely go through a few tutorials (most importantly meta surfaces) - there is a simple one on a yacht hull that should really help you understand the basic concept.

However, I also created a very simple feature inside your project that allows you to create the main meta surface (from cpc, two knuckle curves and the deck contour). Additionally I used two coons patches for the bow region to close the hull and put everything inside a BRep.

 

 

Boat_2.fdbc

[Help for Beginners]

Hi Chris,

 

sure, take your time. What I have done with the generic curve is basically two things: I combined two planar curves into one 3D curve and at the same time took care of the parametrization as I want the rulings of my ruled surface later on to represent sections at a constant x-Position.

 

Therefore I 'walk along' the cpc and get the x position for every parameter t. That's what is written in the x(t) field of the generic curve 'in3D'. Again, the reason why I choose cpc to take the x-positions from is that I already have in mid that I am going to use the 3D curve + cpc for my ruled surface so I want them to have the same x position for each parameter t. 

Now for y(t) I do NOT just walk along the parameter t of the curve that defines the y position (named 'zView'), but rather find the intersection of zView at that same x position. Hence it is zView.fv(0,x(t)):y.

For z(t) then follows yView.fv(0,x(t)):z.

 

Of course this is something you can use to play around with. By changing the parametrization of the generic curve (open up the general tab in the object editor after selecting the curve) you can affect the shape of the ruled surface - see the attached screenshots... You can even use a custom parametrization function to allow for maximum flexibility.

 

  

 

Best regards,

Heinrich

 

 

[Help for Beginners]

Hi Chris,
 
i took a look at the file and prepared a small demo for you.
 
I would not worry to much about using the imported curves if you are aiming for a fully parametric model. Rather use them to guide your eye when creating a new model from scratch.
Basically, what I would suggest is that you try to recreate the design curves of the hull such as cpc, knuckles and deck and parameterize those curves. Getting from those parametric curves towards a complete hull should be easy. You could simply use ruled surfaces between two curves and add all those surfaces into one Brep. You might even use developable surfaces here having an affordable construction of the hull in mind...
 
I just added a scope named 'exampleApproach' to your file in which I started from scratch. If you click the small icon to the right of the folder you get a nice overview of all the design variables contained and you can play around with the sliders to see how the model adjusts...
 
I hope, this helps to get you started! I would also like to recommend you to go through the provided tutorials to get more familiar with CAESES and parametric modelling.
 
Best regards,
Heinrich

 

boat.fdbc

[optimization with batch mode]

Hi Moo Sung,

 

to start a design engine in batch mode you can use the command yourDesignEngine.run(true)

using .run(true) takes into account the existing result pool (e.g. links the designs already evaluated in different runs) while .run(false) will not take into account any previous runs.

This way you should be able to run your design engines one after the other.

 

Cheers,

Heinrich

[Constant volume kept during DAKOTA-Optimization]

Hi Felix,

 

the way I usually handle this kind of problem is via a nested optimization (usually a Brent algorithm works fine).

 

The idea is, that whatever you want to vary within you parametric geometry, there should be a design variable that 'counteracts' the change in displacement to keep the displacement of the model constant for each variant. This could simply be the draft that gets adjusted to ensure that the displacement is the same for each variant, but it could also be some kind of fullness, the mid ship length, etc. (even a combination of different parameters can be used...)

 

The way to set up the nested optimization is as follows:

 

Set up your design variable (the one that will counteract all other changes in geometry to keep the volume constant)

 

Set up a parameter that defines the quadratic error: error=(targetDisplacment - currentDisplacement)^2

 

Set up a Brent that uses the design variable as an input and the error as objective

 

Set variant creation to false (this will internally run the optimization without creating each variant)

 

Set keep up to date to true (this will trigger the Brent whenever the geometry changes so that the displacement is always at target)

 

I attached a simple example for you to better understand the procedure.

 

Kind regards,

Heinrich

constantDPLtestcase.fdb

[2d drawing of brep]

Hi Bram,

 

I took a look at your file - it seems to do what it is supposed to do so far... Would you need further guidance?

 

BR.

Heinrich

[optimization]

Dear Mohamad,

 

From the screenshot I can see that you get the same results for each design variant. Have you checked the result files we talked about earlier within each directory? Are they also all the same? It might be, that your geometry does not change upon changing the design variables - have you compared the exported STL files of the different variants?

 

Best regards,

Heinrich

[introducing initial population to MOGA by DAKOTA]

Dear Hamidreza,

please use the following custom template. As for the *.dat file, you need to format it in komma-seperated columns for the design variables followed by the evaluations. The Location of the *.dat file on your computer needs to be specified in the template in line 11.

 

If you leave the columns for the evaluations empty, dakota will create the same designs, but run the computations and evaluations again.

 

Best regards,

Heinrich

#name Global Optimization

#docu 
Global optimization using the genetic algorithm MOGA. It can be used for global optimization tasks. Note that, in general, genetic algorithms need many evaluations. This makes this method suitable only for problems where the evaluation is not too expensive.
#!docu

method
  moga
  output debug
# set absolute path to existing resultPool.dat file:
  initialization_type flat_file = '\resultPool.dat'
  crossover_type shuffle_random
  num_offspring = 2 num_parents = 2
  crossover_rate = 0.8
  mutation_type replace_uniform
  mutation_rate = 0.1
  fitness_type domination_count
  replacement_type below_limit = 6
  shrinkage_percentage = 0.9
  niching_type distance 0.15
  postprocessor_type
  orthogonal_distance 0.05
  convergence_type metric_tracker
  percent_change = 0.05 num_generations = 10
  <max_function_evaluations, unsigned, 300, Max. Evaluations, set maximum number of function evaluations>
  <population_size, unsigned, 100, Initial Population Size, set size of initial population which might change during the run>
  <max_iterations, unsigned, 10, Max. Generations, set number of maximum generations>
 
variables
  continuous_design = [dv_count]
  initial_point [dv_initial_values]
  lower_bounds [dv_lower_bounds]
  upper_bounds [dv_upper_bounds]
  descriptors [dv_names]

responses
  objective_functions = [eval_count_objective]
  nonlinear_inequality_constraints = [constr_count_inequality]
  nonlinear_equality_constraints = [constr_count_equality]
  no_gradients
  no_hessians
  
[interface]
  asynchronous
  <evaluation_concurrency, unsigned, 8, Parallel Evaluation, number of concurrent designs, General, 3, false>

[optimization]

Dear Mohamad,

 

for further support please grade up to the latest version 4.2.1 and provide your license number.

 

Kind regards,

Heinrich

[optimization]

Dear Mohamad,

 

which version of CAESES are you using? (in the menu click help-->about)

 

Best regards,

Heinrich

[How to avoiding taking some old optimized results automatically when I run a new optimization?]

Dear Yanxin,

 

alright then, hope you are making good progress...

 

Best regards, Heinrich

[How to avoiding taking some old optimized results automatically when I run a new optimization?]

Dear Yanxin,

 

in this case it is hard to say what causes this behavior. Are you able to reproduce the error. Maybe run the NSGA2 with only 4 designs, delete it from the design folder inside CAESES (click 3 times delete in the following dialogues), re-run it and see weather some no-existing designs get recycled...

 

Another option might be for you to attach the fdb file so I can take a closer look...

 

Best regards,

Heinrich

[How to avoiding taking some old optimized results automatically when I run a new optimization?]

Hi Yanxin,

if you delete a folder within the Designs folder (first Screenshot of yours) and delete everything in the following dialogue - there should be nothing left... However, whenever you start a design engine you will get asked weather you want to take any of your previously generated designs into account "use as result pool". If you don't select any of them they should not get used for the current run and hence you don not need to delete them beforehand.

 

Best regards,

Heinrich

[optimization]

Well, then it can't get read in. Is your external computation running? You need to make sure that your external computation is executed correctly (set it as an executable and provide the necessary arguments or alternatively provide a script that takes care of everything as an executable...) - then the result file should be generated in the a.g directory.

What does the task manager show during execution?

[optimization]

Hi Mohamad,

 

soryy, I did not get that last part. Is the file h0.csv in C:/Users/mohamadreza/Desktop/caeses_prop/manual_results/baseline/computation/ ?

 

If not - that's the problem, if yes, try to use this exact file as a template file.

 

Best regards,

Heinrich

[optimization]

Hi Mohamad,

 

Do you get any results when you run the computation manually (by clicking on the eval_h0 parameter and then the small red arrow...) ?

Is the h0.csv file showing up correctly in you results directory?

 

Maybe simply try to remove h0.csv from the result values and add it again. Then recreate the eval_h0 parameter. Just to make sure everything lines up correctly.

 

Best regards

Heinrich