Leaderboard

Hi everybody, I recently tried my hands on integrating CAESES with fluent and i think its worth sharing for those who work with fluent and will like to use CAESES parametric models. Please find attached a copy of my project file. its a simple meta-surface elbow i designed with an ellipse curve.Functions for the "width and "height" of the curve are defined. you can have a look at how parameters are set from function curves. I used ICEMCFD as my meshing tool and Fluent as CFD solver. specific files such as the *.rpl and *.jou were used as input files( checkout the attachments). Absolute paths should be changed to relative paths via "getdesigndir()...." (not all paths are necessary!). A *.bat file, RunFluent.bat, was used to run both ICEMCFD and Fluent in batch mode. Snapshots, graphs etc from fluent can be included as results files for post processing. Details on post processing can be found in CAESES tutorials " getting started". You can have a look. Suggestions are welcome. Best regards, Richard "N.B: CAESES is one of the most powerful softwares for tight integration with CFD softwares for DoE and Optimization. All you need to know is to understand how your External CFD software handles its files to know exactly which input and result files to use. it must also have the capability of running in batch mode." Project1_elbow.fdbc

Those of you that attended last year's user's meeting in Berlin already got a glimpse of some pretty exciting new functionality. For those of you that couldn't make it and because it has progressed into an actual releasable feature (once it has passed the testing phase, that is), let me give you a short introduction. Ok, I am sure all of you know the SshResourceManager, right?! ... NO?! Hmpf, OK. The SshResourceManager (SSHRM) is a light-weight grid-engine shipped with CAESES that allows you to run your external (CFD) solvers on remote computers (sorry, it is not usable with the CAESES free). So, for example, your solver only runs on Linux but you prefer working on Windows with your workstation? No problem, use the SSHRM to act as a bridge to that Linux machine. Your external code should run on that super powerful 128 core machine in your basement? Use the SSHRM to start it there. You have a bunch of computers standing around in your office and all those CPUs/cores inside of them are bored all the time? Use the SSHRM to put those CPUs to good use. The only requirement is, that the computer(s)s you want to run your external code on is (are) accessible through SSH (hence the name SSHResourceManager). Don't worry, there are SSH-servers for Windows, too... The SSHRM is shipped with a detailed admin guide, so the setup should be pretty straight-forward. Don't be scared (it's no Voodoo, really - and we are always willing to help). So, now that we got that out of the way, let's get to the point of this entry: The SSHRM is great to distribute the workload of your external solvers to the resources you have available in your network. It does not only keep track of the CPUs that are currently in use, but also helps you to make sure those expensive licenses for your CFD programs do not go idle (but are not overused at the same time). The SSHRM may even be helpful if you do not want to use remote computers at all, but just need to make sure that your floating licenses users do not block each other. Even if the actual program runs locally on the engineer's machine. I'm drifting off my actual target here, but I just have the feeling too few people know about these possibilities or are afraid of setting up this system. If the latter applies to you: DON'T BE AFRAID! It's really not that complicated and, after all, the good guys at FRIENDSHIP SYSTEMS are always there to assist you. (Did I mention, that the admin guide that is shipped with the SSHRM is really good and thorough?) OK, so where were we, before I went off to tell you how great the SSHRM is? Right... the new stuff! In the next version (4.0 - yeah, baby!) it will be possible to not only run the external code on the remote computer, but run your whole optimization there! Wait! ... What? ... Yeah, you read correctly! ... I know... how cool is that!? Well, of course at least one of your remote computers needs to be running CAESES to enable this option, so license costs may apply... So, the workflow breaks down like this: Start a DesignEngine on your workstation Pause it Close the project If you have CAESES as an application in the SSHRM, you will be asked whether you want to send the project to the SSHRM and have the DesignEngine continue there. If you choose to do so, the SSHRM will select one computer (with CAESES installed) to run your DesignEngine and send your project there. Keep on working on a different project (or a copy of the same one or just do something completely different... I heard that "youtube" is supposed to be pretty good ;) ) on your workstation, your optimization will run in your personal "cloud" controlled by the SSHRM. Every once in a while, check in with the SSHRM through the webinterface in your browser to see the current state of your DesignEngine (basically the Design-Results-Table delivered to your web browser) ... dang.. I didn't even mention that nice new feature in 4.0, yet. I'll get back to that later, Once the DesignEngine has finished (or you decide that it should not run anymore), open the local copy of the project. This will automatically request the project's current state of the project from the SSHRM (of course, you have the freedom of choice. You can just continue the project where you left off). Yes.. this part may take some time, since all that result data needs to be copied back to your machine. If the DesignEngine finished remotely, you can now start post-processing. If it did not finish, you can keep it running locally, abort it, or even send it to the SSHRM again. Number 6. seems to be interesting (imho)... So, in the next version, it will be possible to publish the current state of a running DesignEngine to the network. This means that <note: some technical stuff ahead> CAESES/FFW will start a webserver on a (configurable) port </end technical stuff> that allows to view the current state of the DesignEngine through a web-browser. This is independent of whether you use the SSHRM or not. As long as you are able to access the workstation where the optimization runs through a network, you will be able to monitor your DesignEngine in a browser (even with a dedicated mobile interface if you happen to use your smart-phone or tablet). Even when the DesignEngine runs on your personal workstation, it is possible to "publish" it to the SshResourceManager. In that case the SSHRM will serve as a proxy to the computer running the DesignEngine, so all you need to do is access the web-interface of the SSHRM and it will give you the details of the optimization. Of course, it is possible to protect that web-access with a username and a password. All of this will happen pretty much automagically! Yes... but .... there are some things to keep in mind, when the DesignEngine utilizes external solvers (which it most likely will). If those external processes run remotely through a SSHRM, the remote execution can only succeed if the remote computer running the DesignEngine has the same SSHRM configured as the originating workstation (this is actually the easy case. If this is given, it is possible to pause, close and send a project while a remote process on the SSHRM is running!) If those external processes run locally, the remote computer needs to have the needed LocalApplications configured (preferably to run the desired program). Note that in this case any running processes need to finish before a) sending the project to the SSHRM and B), when requesting the project from a remote executor before the DesignEngine has finished, the system will wait for all local processes to finish before "giving the project back" (step 8). In both cases, during sending, it is possible to run a check on the remote computers before sending the project to one of them (if multiple computers are configured to run CAESES/FFW only those will be considered that passed this check) .... but... yes.... there is some human knowledge required in order to make sure that this works! We tried to automatize as much as possible, but only the user can tell if the external programs that will be launched are actually those that are meant. As a side note (for those of you that are not even closely interested in running anything on any remote computers): In CAESES 4.0 it will be possible to really pause a DesignEngine, close the Project (or the whole program if desired), and open the project later with the DesignEngine continuing to run where you left off (the restrictions regarding external processes mentioned above still apply, though). I know... (again) this was a pretty long read... I apologize! But, somehow I just can't keep it short if there is so much cool new exciting functionality to be introduced... Please let me know, what you think of this, point out stuff that I got you confused with, or (I'd love this the most) give new ideas on taking this even further! Thanks for reading, until next time! Arne P.S.: You made it... have a cookie!

Hi together, please find attached a parametric model of a costa bulb and a feature definition. To recover the energy which gets lost by the hub vortex of the rotating propeller a costa bulb can help. I integrated the rudder bulb setup into the feature "Spade Rudder" which is shipped with CAESES/FFW. The bare hull to which I attached the appendages is also shipped with CAESES/FFW. All you need as input are some propeller parameters. Please find the feature here: baseline > abdy > appendages > feature:rudder Cheers Matthias (fdb file edited, 30.09.2014) containerVesselCosta.fdb

Hi Gabriel, Maybe using fv_all() command would be a better alternative. Please check the picture below; Basically, the fv_all command provides an objectlist. MyCurve.fv_all(0,myPoint:x) The command is applied to a curve. The first argument "0" refers to x-axis The second argument refers to the value on the selected axis. So result will be a list of points that have the same coordinate component value in the referred axis. As seen on the picture above, the curve would have two locations with the same x-coordinate value. Using "at(1)" I pick the second item within the objectlist (0 would be used to pick the first one). And finally I cast the entity to a FVector3 type object. Please let me know if you need further assistance. Cheers Ceyhan

Wow, has it been that long since my last entry? Well, I have a very short one with a big attachment. I always wanted to write something about "best practices" for Feature programming. That "something" became larger and larger and it became pretty clear that it's too large for a "regular" blog post. That's why I decided to create a PDF file, instead. In the end it turns out to be a 37 page booklet instead of an article. I compiled some techniques that I consider to be the most effective for creating Feature definitions with good performance. So, please take a look at "Effective FPL" and let me know what you think about it in the comments. Merry Christmas and a good start into 2016!

It can be quite frustrating... You have an unbelievable powerful computer with the latest CPU. However, when using CAESES, you need to wait for your model to update (or your project to load) while you see that only one of those eight CPU-cores is actually busy and the others are playing a round of poker?! If you know this feeling, this post is for you! (If you do not know this feeling... read the post anyway... big things are coming our way ;) ) Those that attended last year's European User's Meeting already got a short glimpse into CAESES' future from Stefan Harries' talk. So, I figured, I could elaborate a little... So, deep down in our "labs" we are working on the "next generation" of CAESES (I will, from now on, refer to it as ngCAESES, in lack of a better name just to make it easier for me - no, I will not throw any versions number out there). While this "next generation" does not include awesome new features (well, of course it does, but we don't need a "next generation" for that, we just throw those great new features out there as they come along ;) ), there are a lot of changes on the inside - the heart of CAESES. However, it is not only different, but also better. The main benifit for you - the user - is, that everything will be a lot faster (provided that you have a multicore CPU). Before going into some (boring - and maybe also painful) details, I want to give you some numbers... You probably know the "Bulk Carrier 55000 Tdw" sample that is shipped with CAESES (if you don't, you are probably not a naval architect, but even then you should check it out; it's a great model built by one of our most talented engineers). So, in the current release (3.0.17 Windows 64 Bit) the model takes about 14 seconds to load on my machine. When I open that project in the ngCAESES I am up and running after 2.5 seconds! (Disclaimer: The mentioned version is in "hot" development, i.e. a lot is happening and the current state is very temporary. The mentioned timing will most probably change for the actual release - hopefully it will go down even further). Of course, this does not only affect project loading but also model update times and overall responsiveness, but project loading is the easiest thing to measure.... So what do we do to achieve this? Does this mean the ogCAESES ("old generation") did bad things and we finally fixed that? No! It wasn't bad, it's just that now it's better ;). Ok, so we actually took several steps (and are still taking more) to achieve this. The main idea is to utilize the available hardware as much as possible. Watch out! Geek-Speak ahead! The thing about that hardware is, that modern CPUs are not very fast considering clock rate. Well... of course they are blazingly fast compared to old 486 CPUs, for example, but compared to, for example, the Pentium 4 Prescott CPU from !2004! which had clock rates from up to 3.8 GHz, the clock rate did not go up at all in the last 10 years (I know, today there are more instructions per cycle, higher FSB, yadda, yadda, yadda... still, the point is valid). There are several reasons why the clock rate could not be increased anymore. The two main points were (and are) thermal problems and energy consumption (of course, the two go hand-in-hand). So, instead, CPU manufacturers figured it would be a better idea, to put several processors on one chip. That way, they cannot process a single task faster, but perform multiple tasks at the same time at the same speed as the single task. For us software developers this was "black friday". Afterall, it means that we do not get speed improvements for free anymore, but we actually need to work for it, because in order for the CPU to execute our software faster, it needs to be split into several individual task that can be run in parallel. End Geek-Speak (for now... maybe more later ;)) The following picture (which was also shown at last year's User's Meeting in Berlin) tries to illustrate the difference: So, what we can see is, in the current version (up top in the picture) objects are updated serially - ordered by their dependency. Some objects already make use of the multiple cores the CPU provides, as they calculate some stuff in parallel (the last box), but that is rare. NgCAESES (bottom - labeled as CAESES 4, but I, personally, don't want to throw any version numbers around) builds a graph of dependent objects, and different branches of that graph are then updated in parallel. Additionally, a lot more objects have their internal algorithms parallized. This - as you can clearly see in the picture - leaves you - the engineer - a lot more time to travel, relax, and party ;) With great power comes great responsibility Yep... that's true. It cannot be all gold and shiny. But, the nice thing is, the drawbacks will only affect those people who were already told by us that what they are doing is "evil" or "out of the specification" in the past - I am pretty sure that (if they are reading this) they will know that I am addressing them... Ok, so we needed to limit the freedom and flexibility the user had so far a little. You cannot use features to "mess everything up anymore" ;). The major change for the user (which "average Joe" will not even notice) is that we introduced the notion of "constness". Those of you that know C++ (or C#, or Ada, or D, or one of the other programming languages that make an explicit distinction between constant and mutable expressions) will know that this can be quite painful, but also very good for guaranteeing that nothing bad is happening in your code. So, what did we actually change for the user? What is not possible anymore? You cannot call a command that modifies the object it is called on anymore, if that object is labeled as "const" and the command isn't. You cannot pass an object that is labeled as "const" as an argument to a command that takes a non-const argument. That's it..... I can literally see your face right now: :blink: :blink: :wacko: :unsure: :wacko: :blink: :blink:. So. please let me explain: When is an object const? I think that is best explained through an example: You can ask a F3DPoint for it's global vector by using the command FVector3 FPoint.getGlobalVector() The return value of that command is (now) const. Why? Easy: The command returns a value that is a derivative of the point's input values (the x, y, and z coordinate). Changing that return value would not result in a change of those values. They are what define the point and also the global vector. To make this clear, the return value is now marked as const and will result in an error when trying to modify it. So in the past it was actually possible to write nonsense like this (provided there is a F3DPoint called p1): p1.getGlobalVector().setX(8) It was valid, but didn't do anything. Of course, the "didn't do anything"-part means it didn't do any harm, but if the user (i.e. YOU) would execute something like this and not get an error message, the understandable assumption would be that it DOES do something, is quite understandable. But, not only is the return value of "getGlobalVector" const, but the command itself is also const, because it does not modify the object it is called on (i.e. the point). So in ngCAESES the complete signature for that command is const FVector3 FPoint.getGlobalVector() const The first "const" refers to the return type. The returned object cannot be modified. The "const" at the end refers to the command in respect to it's receiver (i.e. the point it is called on). As stated, that example is harmless, but there are several not so harmless cases, that lead to undesired behavior. One more example: Let's assume you have a point p1. Let's further assume you have a parameter pm1 that defines the x-coordinate of that point. Now, for whatever reason, the user enters the command "p1:x = 9" in the console which is supposed to set the x-coordinate to the value 9. Well... it does set the x-coordinate to the value 9 (i.e. the point will actually be there), but it will leave you with the following undesired state: So what do we have here? The parameter pm1 has the value 1, the x-coordinate of the point is still set to be said parameter, but the actual value is 9?! That can't be right! So what happened? Well, without going into too much detail: p1:x returns a FDouble, which is then assigned to using the '=' operator. Nothing bad about that. BUT! p1:x does not really have a double as a value, but an FParameter. That FParameter is (automagically) converted into an FDouble (while the conversion is pretty straight forward in this case, it's still neccessary). So the p1:x actually returns a temporary FDouble that is the result of the conversion of the parameter pm1 to a (temporary) FDouble. And now, the operator '=' assigns the new value '9' to exactly that temporary FDouble. In turn, this means that the wrong state is resolved after changing the parameter (because the temporary FDouble will be replaced by a new temporary FDouble) or after re-opening the project, but it's still bad that this state can occur. Ok, to be honest, I probably lost most of my readers (if you even got this far) with that last paragraph... Read it again... It might just make sense eventually... So, the main point is: we are trying to protect you from experiencing something unexpected when using our software! We are well aware of the pitfalls, but we are also aware of the great power and flexibility we offer. So, we want to keep the flexibility and power while reducing the possible pitfalls (now that's something the C++ commity should have decided at least 10 years ago). That's why in ngCAESES stuff like assigning a value to p1:globalX will not be possible anymore. How does this affect me? Short answer: It doesn't (or it shouldn't). If you do get an error because of this (and you should not), it means that in the past you were doing something that had (in the best case) no effect (like the .getGlobalVector().setX(9) case) or really, really bad effects (like the p1:x = 9 case). With regards to Features there are some things, however, that used to work and will no longer work.To be honest, those things are things, that we never promoted and even told those that used them that they shouldn't. I am kind of hesitating to include them in this post, since I do not want to give those people that didn't do this or didn't know that they could do this any bad ideas... Ok, I am still gonna do it... First of all, it will no longer be possible to change (i.e. call non-const commands on) arguments of a Feature within the Feature. Why? Watch out! Geek-Speak ahead! (but this time all CAESES users should understand it...) Well, technically, the Feature is a client of the argument. When the argument changes its value, the Feature needs to update. So, changing the argument value within the Feature actually creates an untracked recursion. The only reason it worked until now was that there was a safety-net in the code that made sure that objects cannot go out of date while they are updating. But... it also left the whole model in an undefined state. Some other objects that were clients of the object that the feature changed may have already been up to date, and they never noticed that the object has already changed its state... This is not good! Kind-of done with geek-speak, but the following may still be kind of tech-heavy! So... we are totally disallowing to change arguments of a feature within a feature. This will not be the case in the upcoming 3.1 release, but I hope, it will be in the one after that! Ok, so those Features that I know that did change their arguments did this for one - and only one - reason: display the user some additional info. Since we know and understand, that that is a good thing, we have introduced a new thing (not yet, but in the release that will include all that "const" stuff): You can now tell a feature argument that it can act as a label. The "advanced options" of feature arguments have 5 more fields (names are subject to change - so don't quote me here): - "Display as label command": Here you can specify under which circumstances the given argument is supposed to display a value and nothing but a value... The value displayed has nothing to do with the value of the argument. If it's supposed to be a value only, you would set this to "true" or if it depends on the state of the model or other input of the feature you can use the usual command syntax. If this command evaluates to "true", the editor for this argument will be hidden and a label will be displayed instead. - "Label Content Command". If the above determines that this argument is displayed as a label... here you can say what the label is supposed to display. This can be just a string, or any other object. If it's anything but a string, the usual display as a string will be used that applies to the type (e.g. if it's a fvector3, it will be displayed as [1,2,3] if it has x = 1, y = 2, z = 3). This label is very flexible! It can even display HTML! So, go crazy with it! - "Keep Label UpToDate" If this is set to true every object that is needed to determine the value of the previous two commands is automatically updated as soon as their value changes (same as automatic update for parameters/constraints/features: I do not recommend to use this option - or better: use at your own risk!) - "Hide Check Box for Label". If the attribute has a "Display as label Command" (see above) and that command evaluates to "true", the checkbox (see the documentation about the advanced options of feature arguments in versoin 3.1) will be hidden. - "Hide Buttons For Label" If the attribute has a "Display as label Command" (see above) and that command evaluates to "true", all buttons configured for the attribute (see documentation about the advanced options of feature arguments in version 3.1) will be hidden. Wow... this is a terribly wrong post.... To all of you that are still here... HAVE A COOKIE!!! OR TWO!!! I just wanted to share some of the new development with you - that I am personally very excited about. Also, I wanted to warn some of you Feature-Artists that some of the freedom is coming to an end ;)

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

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

Hi Manoj, You can access the CAESES documentation in the Help section in the software CAESES. In the documentation you will find the "Fine Marine Pre-Processing" tutorial under Tutorials > Maritime > Software Connection > Fine Marine Pre-Processing. Cheers, Hedi

Hi Manoj, usually, you start with a working setup that is capable to be run from the command line. This is entirely FM-specific and outside of CAESES. In the current version of CAESES we provide a tutorial on the geometry preparation for FM, based on the Maritime Workflow introduced in CAESES 5.3. Assuming you've got the latest version of CAESES installed, you can find it here: http://localhost:65038/tutorials/maritime/software-connection/fine-marine-pre-processing . This geometry should be exported either as parasolid or as multibody stl. At this point the above-mentioned workflow comes in. Please identify all relevant input files and provide them from the software connector. Define case-specific values by parameters. Put the command you used to run the setup from the command line into "ExecutionSettings|Arguments" (possibly preceded by "bin/bash"). Run the case for one geometry from the software connector and define all relevant result files within the software connector for further post-processing. Hope this helps! Cheers, Hannes

Hi Thomas, Your code seems to work fine and sets the knot vector correctly for the b-spline curve. However, the display field of double series attributes in feature definitions has a small bug. So to see the values of the knotVector doubleseries you can drag and drop the "knotVector" into the console field and press enter. Cheers, Hedi

Hi Furkan, If you set up a "Response Surface Optimization" and choose to "use result pool", a surroate will be created (if your pool is large enough, otherwise samples will be added first). An optimization on that surrogate is performed automatically in the background (a Genetic Algorithm is used here) and the optimal candidate (or multiple if you choose so for a multi-objective problem) is returned. The design you see created in CAESES is therefore either an additional sample or already the potential optimum. Check the dakota.out file in your design directory to see the details. Also, the finaldata file will show you the predicted performance of the optimum... If you keep this Algorithm running, the actual (CFD) result(s) of the optimum-candidate(s) will be added to the pool for the next iteration and the process repeats. Cheers, Heinrich

Hi CJ Coll, I edited the feature so that the labels are not on top of each other anymore and the points are removed inside the profile view. You can find the edited linesplan feature attached to this reply. To toggle the visibilty of the orientation points from the group section curves, you can use the command .setShowOrientation(true/false). If you want to further edit the feature yourself, you can access the it in your CAESES installation directory under "CAESES...\etc\features\features\Maritime". To add a line that follows the topdeck, my solution was to create an image curve from the hull's surface/brep upper edge. I hope that solves your problem. If not, don't hesitate to ask. Linesplan_edited.fde

Hi Yukai, The force in the last line is the converged value from the solver. I would suggest to use a python code only for post-processing. For example, if you want to plot the convergence history of the forces over OpenFOAM iterations. By parsing various values, such as force in x-axis to parameters and establishing a robust integration CAESES with OpenFOAM, then you can continue with a Design of Experiments and/ or with a Optimization process. Best Regards, Andreas

Hi Yukai, OpenFOAM is notably complex when it comes to managing numerous processed files. To address this complexity, I've included a screenshot featuring a standard connection input file, geometries, output files, and corresponding values. It's advisable to consistently employ relative paths by utilizing the subfolder option, as illustrated in the second screenshot. To extract parameters from the force.dat file, you can directly navigate to the last line, which typically represents the converged value from OpenFOAM. This can be achieved using the -1 option in the command line. Moreover, consider incorporating a Python file for post-processing and integrating it into your connection. This can be facilitated by incorporating the Python script as a command line within the Allrun.sh executable file. Best Regards, Andreas

Hi Gustav, you could create a point through the console with: point p(curve.fv(2,zVal)) Instead of "curve" you'll have to choose your particular curve and zVal would be your z value. "2" corresponds to the z-axis (0=x, 1=y, 2=z).

Hi CJ, I guess I would just create a planar BRep intersection (BRep-based curves) and from this get the area. See attached project... Cheers, Heinrich fishingVessel.cdb

Hi Carlos, Yes. A student license includes the complete functionality of CAESES. See https://www.caeses.com/products/caeses/editions/#students . Cheers, Carl

Hi Carlos, the SSH Resource manager is an addon to CAESES which has to be purchased separately. After purchase, the SSH Resource Manager Server must be installed on a host in your network, e.g. the cluster main node. If you have installed this already, please ask your network manager where it is installed. Best regards, Hedi

Please insert a reasonable knotspacing value in the BRep and datareduction afterthe transformation. The transformation might otherwise rip the geometry apart, since it moves the control points of the vessels representation. In the flat of bottom area there might be only a few and that needs to be refined. Cheers Claus

Hey, I' ve created two feature definitions for importing and exporting of point data. Import: The file is read line by line. To create the point as objects you have to create the feature defintion via execute Defintion (right click). The point data in the csv or txt file has to be separated by white space or comma by default. You will find attached the project, the feature definitions and two example files as a zip file. Best regards Karsten ImportPointData.fdf writeCsv.fdb exampleFiles.zip ReadAndWriteFiles.fdb

The model is unfortunately very bad. There are big gaps between several surfaces. I will see if I can find a repaired one. Best Regards Claus

I think so ...

Hi Hedi, thanks a lot! Problem solved! Now it runs really smooth on my computer. 🙂 Best regards, Yanxin

Hi David, You can display calculated values in the input dialog by defining an additional argument and editing the advanced settings of the feature argument. Here is a video tutorial on how to show result values in the input dialog. Drop down list for input values In addition, you can use String Options to choose an input value from a drop down list. Make sure you switch off the field "Allow Expression" when you use it. By using a "switch" you can define the method you would like to use for your calculations. FString chosenmethod(method) switch (chosenmethod) case "A" echo("using calculation method A") case "B" echo("using calculation method B") case "C" echo("using calculation method C") endswitch Here is the feature definition example that includes the result values in the input dialog and the switch cases with the string options for your reference. DynamicArguments_WithResultField_DropDownListOptions.fdf Have a nice day. Hedi

There is something, that seems to be related to the weight of the third point. But maybe it also comes from the curve intersetion point, there seems to be a discontinuity in the definition, see screenshot of control polygon. That is where the "folding" appears in the visualization.

Hey, I am doing some hydrostatic calculations. I did not find a way to calculate the wetted surface of a boat in the hydrostatic tool. How do you calculate the wetted surface? Thanks.

Hi together, The software CAESES is a CAD and optimization platform. For students and PhD students there are free non-commercial licenses available. In addition, there are low-price offers for start-ups and smaller companies. CAESES can be used for 2D and 3D parametric modeling, see this link for some information about its CAD capabilities. Here are some screenshots: Compared to traditional CAD systems, CAESES is a bit different. It comes with a strict object-oriented approach, i.e. the user sets up dependencies between objects and these dependencies are then kept. This makes it easy to automate the geometry generation process. Here are some features of CAESES: Full 2D and 3D modeling capabilities (NURBS-based)Roughly 20 curve types and 15 surface typesStandard transformations (translation, rotation, scaling)Writing of custom features and functionsBoolean operationsTrimmingFillets between surfacesMorphing functionality for deformation of existing geometrySurface tessellation control through e.g. trimesh objects to create and fine-tune custom STL dataCommon import and export formats e.g. IGES, STEP, PARASOLID, STLIndustry-specific modules for blade and ship designBatch mode for non-GUI (hidden) geometry generation in the background Cheers Joerg LAST UPDATE: NOV 2017

CAESES provides comprehensive functionality for propeller and fan designers so that it can be used as an expert blade design software. Basically, any kind of propeller blade (e.g. boat propeller, aircraft propeller, blowers, fans etc.) for any application can be created with it. CAESES focuses on the variable geometry of blades for design explorations and shape optimization (mostly, together with CFD). Here is a screenshot for an axial blade design, taken from one of the samples that are shipped with CAESES: For general information about modeling of propellers, see the MARINE SECTION. For other rotating machines, please see the TURBOMACHINERY SECTION. 2D PROFILES 2D profiles can be defined by the user. These can be either parametric (e.g. camber curve + thickness distribution) or based on profile data from an air foil data base. There are models available with special definitions such as Wageningen B-Series. NACA curves are also available in CAESES via the menu > curves > naca. When generating the 3D propeller surface, the profile parameters can be changed by means of radial functions for each 2D parameter (e.g. chord, camber, thickness). IMPORT AND EXPORT In order to import or export the blade in a proprietary format, feature definitions can be used which allows you cope with e.g. company-specific ASCII formats. The PFF (Propeller Free Format) is directly supported. EXTERNAL TOOL / CFD AUTOMATION Any preliminary design tool (XFOIL etc) or even CFD packages (in-house, open source, commercial) can be integrated so that a new design can be analyzed within CAESES. BLADE ANALYSIS There is a functionality that can analyze an imported blade surface (given as NURBS) to give you the chord, rake, skew, pitch, thickness and camber distributions. CUSTOMIZATION There is a lot of scripting possible in CAESES so that any specialized design process can be fully transferred into the platform. For instance, if you use Excel sheets for your profile definitions, you can access them through CAESES but also re-implement your methods using the feature definition programming editor. EXAMPLES Some propeller design case studies can be found in this section. If you are interested in drone design, then check out this post here. Here are some videos - the last one I put there only to give you an impression about how the geometry controls can be wrapped and accessed for applying changes, this can be done for all other types of blades as well. Wageningen Propeller ModelPropellerBlade Tip DesignGeometry Changes for an Axial Fan (and a Ship Hull) - Demo Video ONLINE TOOL Finally, check out the new online geometry creator for the Wageningen B-Series. Browser-based, intuitive web app.Allows you to generate typical B-Series propellers with just a few clicks.Requires very little propeller design expertise.The final geometry can be downloaded as STL or STEP file. LAST UPDATE JANUARY 2018 Note that there are FULL FREE ACADEMIC versions of the pro edition CAESES for students and PhD students as well as trial licenses with variable time frames. There are also special editions for small companies, start-ups and freelancers.

Hi Rizuan, very good. FINE and CAESES are well known combination so hopefully it will be 'smooth sailing'... Cheers, Heinrich

Hello, Lately, I’ve been trying to run CAESES coupled with StarCCM+ in batch mode for Linux. Checking previous discussions, is it possible to reactivate again for downloading the zip file with the example on how to run CAESES in batch mode? and if you have suggestion please feel free to tell me Thanks in advance, Best, Nuttarat

Hi Nicolas, The Export type you require is "STL (Extract Colors)" In CAESES, please create a scope, let's say "02_Export". Then please locate the BRep/s you want to be exported. Please be sure that, the geometrical entities you want to be seperated do have separate colors assigned. Then select the folder, change the file type to "exportStlExtractColors" and provide a file name. Using this procedure, whenever you create an fsc file, the export information will be written automatically. Please let me know if you have further questions. Cheers Ceyhan

Hi Farzan, The operation "Solid From Intersections" tries to obtain a solid "water-tight" geometry from the combination of several provided geometries. The reason why the operation provided some unsatisfactory result maybe due to your provided inputs were not much intersecting but flush maybe? From the pictures it is not quite clear but is there even some fillet? I will recommend you to extend the blade geometries a bit so that there can be a proper intersection among the geometries and create the fillet afterwards as a separate operation. Please let me know if you need further assistance. Cheers Ceyhan

I have used the Hydrostatic tool with closed trimeshes. The sections displayed below the hull look broken like in the attached example. If I use an open trimesh, the sections look alright. In both cases the calculated values are the same but I am not sure what the broken sections want to tell me. In my current project I only got .stl-files with closed trimeshes of hulls so i can not use the surfaces to do the calculations. surface_trimesh_trimeshclosed.fdbc

My doubt is actually not hard, but with the actualization i lose a feature i used to use. Here is the situation: I need to create some points on this curve and each point on the top has its correspondent on the bottom exactly on the same elevation in X axis. To do this i need to use the parameter witch corresponds to the elevation required, but in X axis the curve has 2 possible coordinates so that once i insert the function related to the creation of the point only one coordinate (on the top) is selected. Previously i could use "PointIntersection2D" and select a index, witch allowed me to choose any intersection the function would find. Here is an Image of the situation: The question is: is there any function or any oder way to select another index on the curve? P.S.: I could split the curve in two new curves, and repeat the steps, but i'd like to know if there is a solution like the feature i used to use.

Hi together, If you want to change the rotational direction of a propeller blade (type FGenericBlade), then you can simply switch the orientation. See the attachment for more information. Cheers Joerg

The easiest way to flip the normal of a given surface is by reversing one of the surface directions u or v. In a NURBS/B-Spline surface this can be done with the command .reverse(1,0) or .reverse(0,1). In a Metasurface you can reverse start and end position or you create an image surface and in the u or v domain you enter [1,0] instead of [0,1].

Hi together, Please find attached a parametric model of a centrifugal impeller which was built in CAESES. The project file will probably also be included in version 3.0.11. Note that pretty much everything can be customized in this model and used for manual or automated blade design, such as: Merdional contour (i.e. hub and shroud contour)Profile shape by means of user-defined thickness distributions and beta-angle distributionsFillet shape at the hub region by using a constant factor (BTW: this can also be varied with a function along the blade)Ellipse factor of leading edgeSize of tip gapRotational directionNumber of bladesThickness of casing The splitter blade is completely decoupled from the main blade in terms of the beta-distribution (so this gives more freedom) - but can be linked to the main blade, too. In addition, the model comes with some support geometries for meshing/CFD ("periodic boundaries"). These are automatically adjusted to the blade shapes. The camber lines of the blades are generated from the trailing edge which makes it easier to vary the beta distributions (e.g. fix the TE ends of the blades). There is also a feature definition included which generates the camber line with the leading edge as starting point. When working with the model, switch off all scopes that are "downstream" of where you currently manipulate things. For instance, if you want to change the hub and shroud contour, then set the scopes 02_main, 03_splitter and 04_cake invisible. If you want to change the beta distributions, only visualize the sections that are given in 00_sections. This allows interactive changes to the model with a very short response time. You can also switch off the cake part since it is only there for visualization purposes and CFD pre-processing. Let me know what you think about the model (of course, I hope you'll like it....). Cheers Joerg UPDATE AUGUST 2015: There are new samples directly included in CAESES that you can use for impeller modeling. See my more recent post below. The project files in the attachment do not work correctly for CAESES 4.x versions, we now have much easier ways to design and control hub fillets. UPDATE FEBRUARY 2016: I removed the old project file and added an updated CAESES model to this post. Should work with versions >= 4.0.3. UPDATE FEBRUARY 2017: Note that there are now FULL FREE ACADEMIC versions of the pro edition CAESES for students and PhD students as well as trial licenses with variable time frames. There are also special editions for small companies, start-ups and freelancers. FS_CENTRIFUGAL_IMPELLER.pdf turbocharger_easyuse.fdb

Hi, Suppose you have several educated guesses about the possible shape of your product but you are not sure which one of your shapes or which combination of these shapes will be the most suitable for a particular purpose. (Examples from naval architecture: Three different bulbous bows or two different stern configurations -- all look good and reasonable but what is the best mix?) One way to set up a parametric model (a partially parametric model to be more specific) is to use morphing, i.e., the smooth transition from one object to another by weighting. Suppose you have a cat and a dog. They look reasonably alike (two ears, two eyes, one snout etc.), meaning their topology is the same even though their geometry differ. If you set your weight to 100% cat and 0% dog, well, you get the cat. If you do it the other way round you would have the dog. Anything in-between, say 60% cat and 40% dog, makes an interesting mix, a cat-dog so to say. (No way to produce a donkey, not even by extrapolation.) Within CAESES / FRIENDSHIP-Framework you can build on this idea by utilizing one or several interspaceSurfaces. Assuming you have the same topology for your surfaces (matching orders and matching numbers of vertices when it comes to B-splines), you can interpolate between your shapes. Attached please find an example in which several surfaces are morphed. Cheers, Stefan surfaceMorphing.fdb

Dear CAESES/FFW Users, I would like to use CAESES with OpenFOAM: - make very simple parametric geometry - use of snappyHexMesh (as mesh generation tool) - use of OpenFOAM (as flow solver) - modify some basic geometry parameters of the geometry - rerun CFD computations with the modified geometry - use of post-processing tools to compare CFD results between configurations I was wondering if someone has already done this kind of exercise and maybe could share it trough the CAESES/FFW forum ? Best regards, Stephane Sanchi.

Please ensure your export folder has the correct setting as shown in my first screenshot from monday. Furthermore, you could have a closer look what is exported by Caeses when updating a parameter in this file path:

Dear Rohit, the design variables are used to describe/modify the functions given in 01_blade/functions. You can see how they affect their shape in 3D: You can find detailed information on their exact definitions in the documentations. To get there, just click the little blade icon next to the name of the blade: Best regards, Heinrich

If you created the other surfaces with "Coons Patch" by use of 4 boundaries, you could divide the current 2 lines into 4 lines with "image curves" and use them as boundaries for a "Coons Patch"

Hi Mlysyshyn, For sure you can do that as well. Will create the new configuration and send it once I have some time today. Cheers Ceyhan

Hi Mlysyshyn, Please find attached the modified version. Some modifications I have performed; 1) Within the Runner for the "Local Application" I have selected the AllRun.bat which I have created. Please note that I am not using any arguments. 2) The RunAll.bat executable includes commands within the "C:\OpenFOAM\19.10\cygwin64\Cygwin.bat" executable (lines 4-9) and the path to my script file which is the AllRun.sh (line 9) 3) Finally made a little modification to the script file. The final configuration seems to be working but didn't pay attention to the OpenFoam setup. Cheers Ceyhan Sduct_with_openfoam_2_FSYS.fdbc

Hi Mlysyshyn, Can you please share your project file if it is not confidential? You can also send it to erdem@friendship-systems.com so that I can give a look at your SoftwareConnector setup. Cheers Ceyhan

Hi Mlysyshyn, I can see that the files are are moved to their related locations. Can you please share any console output? Or some OpenFoam logs where the problem can be tracked? Cheers Ceyhan

Hi folks please find attached a Feature Definition for a "Bulbous Bow Shape Analysis" and a Feature Definition which can be used in a CurveEngine for creating a MetaSurface. shapeAnalysis_Bulbous_Bow.fdf bulbous_bow_section.fdf [edited 05.10.14 - tangent analysis included] In order to replace a Bulbous-Bow-IGES-Import by a fully parametric MetaSurface you can use this Feature by execute the following steps: Create a Surface Group including all the IGES-surfacesCreate a new Feature Definition and reload the Analysis-Feature, apply and create the Feature by right click on the Feature Definition>Create FeaturePass the Surface Group to the Analysis-Feature and enter (if necessary) start- and end-position in x-direction of the bulbous bowAdditionally give a number of offsets (30-50 should be a good choice)Run the Feature This will create function curves which can be used to create a MetaSurface. The next steps should be: Re-model the function curves by e.g. FSplineCurvesCreate parameters for some values of the new curves, like start/end position, start/end tangent or area Create a CurveEngineCreate a new Feature Definition, reload the Section-Feature and applySelect the Bulbous-Bow-Section-Feature and pass the new function curves to the EngineAdditionally you can set start- end end-tangent valuesCreate a MetaSurface, select the Curve Engine and set the base positions according to the start- and end-position in x-directionNow you will have a single Metasurface, which is parametric and ready for a design study. Cheers Matthias

Hi folks, please find attached a fully parametric model of a WED - Wake Equalizing Duct. Such a device can increase the wake homogeneity and the hull propeller efficiency. In the project (baseline > abdy > appendages > duct) you can find three sets of parameters (in the scope 04Parameters): The first set controls the path of the duct which consists of three parts, an upper flat, an round mid-part and an lower flat. The parameters for the path are shown in the figure below. The second set of parameters controls the section of the duct. The standard parameters for a NACA 4 digit profile (chord length, maximum thickness, camber and camber position) are kept constant but can easily be replaced by functions. The angle of attack can be varied for three positions (shown in the figure below). The third set of parameters controls the global position of the duct. With xpos and zPos you can move the duct to the destination. With totalScale you can scale the duct. Taking into account the direction of the skeg surface (the red line shown in the figure below is a surface curve on the skeg at the height of the center of the duct) the duct aligns to the surface and to the surrounding flow. With the parameter addFlowAnlge you can apply an additional angle which results in a rotation around the z-Axis. The parameter AOATotal effects a rotation around the y-Axis. For external CFD computations you can find a watertight trimesh (imDuctMesh) and the parameter openEdges which checks the watertightness. This parameter can be used as a constraint for the computation. Cheers Matthias WED.fdb