Jump to content

Mr. Heinrich von Zadow

Moderators
 View Profile  See their activity

  • Content Count

    199

  • Joined

  • Last visited

  • Days Won

    9

Posts posted by Mr. Heinrich von Zadow

  3. Posted · Report reply

    Dear Aina,

    I am happy to take a look but would need the project file and/or the exported IGES you mentioned. 

    From the screenshot it looks as if your geometry is not fully watertight -- that might be a starting point for investigation. Furthermore, the displacement calculation is based on the triangulation settings -- the coarser, the larger the error. But typically the deviations here are not as large as you experienced them.

    Finally, if you calculate displacement at a certain draft, heel and trim, the order of transformations and the origin you choose may drastically impact the result. I don't know about Numeca, but in CAESES we transform in the order  heel, trim, draft and use [0,0,0] as default origin. You can also specify otherwise by using the .getDisplacementOrigin() command.

    Kind regards,
    Heinrich

  6. Posted · Report reply

    Dear Solehah,

    thanks for preparing the file. Here's a few comments:

    1. I can see that you have a number of individual Trimesh Parts. None of them has a color. Typically what you would want is a watertight geometry of the domain with the individual patches colored (the color names will be exported as the names of your boundary conditions). I recommend you color the individual parts and join them together in a single Trimesh like this:

    image.thumb.png.c3e87887173c8238c7c3a9c3471cd8d0.png

    2. Make sure to reference to the exported geometry in your sim scripts (maybe I just overlookerd it, but I could not find the file names you used for the exports in there. Lines 8-9 in your existingShip.iec file don't look good.

    3. Your Connector runs the local Application FineMarine without any additional arguments. I imagine that you either need to specify the sim file as argument or, alternatively come up with a batch file that takes care of running things.

    4. If you want to have parameters for certain inputs you will need to assign them to your configuration (i.e. drag & drop):

    image.thumb.png.2f3e77ed1c6475d9d6af3c5a81b9ac48.png

    I'll leave it at that for now. If you still run into trouble, I highly recommend you follow through a few tutorials on the subject. The procedure is always very similar.

    Best regards,
    Heinrich

     

  9. Posted · Report reply

    Dear Solehah,

    you can refer to the provided tutorials on software connection. The basic principles are always very similar. After you have tested things manually you should know what geometry is needed and in which format. My guess is a colored STL of half the domain with the ship substracted from the domain at roughly the right floating condition. Extra care needs to be take to account for triangular patches as I mentioned in my first post.

    If you want CAESES to read in pictures generated from Numeca (or any other tool in your chain), PNG works fine.

    You will want to run Numeca in batch mode to avoid the GUI showing up. 

    Best regards,
    Heinrich

  10. Posted · Report reply

    Dear Solehah,

    at least I can't see anything that's obviously wrong from the screen shots. If you have an STL I would recommend that you start by setting everything up in Numeca (completely independent from CAESES). Once things are meshing and running/converging the way you want them to, you can go back to testing the CAESES integration. This way it's easier to know where to trouble shoot...

    Cheers,
    Heinrich

  13. Posted · Report reply

    Dear Solehah,

    with HEXPRESS Numeca Fine/Marine offers a powerful meshing tool which is well matched to their requirements for CFD. Afaik the input file for Numeca (output in CAESES) would be a domain either half or symmetric in colored STL. The only pitfall I am aware of is, that HEXPRESS does not like triangular patches. Hence, if you have them, you would need to join them with a neighboring patch so that the cells can "float" across the patch boundaries (see below image where I colored the small triangular patch in turquoise instead of grey to avoid the described singularity).

    image.thumb.png.494c07b2a900061ba6d92af12f176578.png

    As an Input to CAESES any text file containing the information of interest (resistance?) should do just fine.

    Cheers
    Heinrich

  17. Posted · Report reply

    Dear Rizuan,

    yes, indeed -- an image surface will always be an image of only one individual surface. You can wrap multiple surfaces into a surface group. An image surface group would then allow you to transform all of them at once. Alternatively, you can use a BRep which also accepts transformations and can have multiple sources.

    Best regards,
    Heinrich

  19. Posted · Report reply

    Hi Rizuan,

    An image surface only accepts surfaces as input, no BReps.

    image.png.dc56f16e093a083a309f76e2ead67db4.png

    You can have images of individual BRep patches (or their underlying, untrimmed NURBS surfaces, to be more precise) by setting "brep1.getSurfaces(0)" as a source. Obviously, 0 can be replaced by any other surface ID... Here is an example:

    image.thumb.png.6ee6fb350ac8926d42ed00959a8dc77a.png

    Note, that the underlying surface of the circular patch is actually rectangular (That's what BReps -- "boundary representation" -- are there for, after all).

    Hope this sheds some light onto the topic. Why is it, that you wanted to create an image, anyway? Maybe there is a different way to get what you are after.

    Best regards
    Heinrich

  21. Posted · Report reply

    Hi Carlos,

    we don't ship anything readily with CAESES but maybe you can start off from an imported geometry -- something like a standard test case (KVLCC2 or similar) and then apply partially parametric modelling techniques such as Free From Deformations or BRep Morphing to vary the shape.

    Best regards,
    Heinrich

×
×
  • Create New...