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 CJ, if you check the documentation for "units" you should find this: Cheers, Heinrich

Hi, you can select the option "Response Surface Optimization in the Optimization workspace. Afterwards, you can check the option "Use Result Pool" It will ask you to select the pools which you want to utilize for the surrogate based optimization after starting the design engine. Please note that if you do not have sufficient samples in your result pool, it will do additional samples before starting the optimization. It will then perform the optimization on the surrogate in the background without calling CFD. After that, a new design will show up in CAESES, which is then evaluated using the CFD to check if it matches the prediction from the surrogate.

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 everyone， I'm having a hard time. I created the blades and tips. As shown in Fig. However, when I create the propeller with Model-propeller-propller, I only get incomplete blades. The tips were not created together. This is shown in the image below. Also, due to the language, I may have a problem with the description not being clear, so please forgive me. Looking forward to your answer. prop_para.cdbc

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 Furkan, at the computation object, there is an option to set a list of constraints. If one of these constraints is violated, the computation will not be executed for that design. Cheers, Mattia

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 Carlos, In principle you are right. The SSH Resource Manager is part of the "entire functionality of CAESES". However, due to the low demand and the current revision of that piece of software, we only grant access on request. So please write your demand via email at license@friendship-systems.com with a short explanation on what you want to achieve with it. And please remind: "CAESES® must be installed on a personal PC/notebook rather than on University computers." "By granting you this free license we expect you to send us a summary report of the work that you have accomplished with CAESES® or a PDF copy of your thesis if applicable." Best, Carl

Hi CJ, from visual diagnostic, it looks like a misplaced point - maybe a sign error or a bad dependency? Actually It depends on how you set up the keel line, especially the point or curve, which is going crazy. You can take a deeper look at the faulty design(s) by double clicking on it at the Result Table, or below the Object Tree at the Optimize workspace. BUT only apply changes the baseline design - every change you make inside an other design than the baseline, will not be considered for further design engines - these are always based on the baseline. But you can try out solutions by unlocking the design -> Search for your keel line and its sources. You can check the dependencies of the problematic curve. Right click on the object inside the Object Tree and select "Show Dependencies" - at the upper left corner of the Dependencies window you can switch "Show Clients" or "Show Supplier". Hope that helps, Best, Carl

Hi, Looking for outsource 3D rendering company. Who do you use for outsourcing 3D rendering? Who do you recommend? Thanks everyone for your recommendation ;)

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, unfortunately, I cannot give you any hints regarding the integration of the .jar libraries in CAESES. Generally, a typical approach would be to - keep the setup (*.jar / *.java) on the cluster separate from CAESES. - just create a text file with all variables to be edited by CAESES and write that to the cluster. - Use a bash wrapper similar to the attached example for SLURM to fetch the setup and launch the runs. This script is called from the CAESES software connector. It is important that the bash script stays alive as long as the run in active as CAESES will be monitoring it and look for the results as soon as it ends. Hope this helps. Cheers, Hannes slurmExample.tar.gz

Hi Carlos, please use a personal message (click on my profile -> message). Out of your last question about starting CAESES in Baseline or in designOfExperiments I assume, that you made a lot of work not with the baseline design. For CAESES each design is its own instance, and they are not connected with each other. So if you doubleclick on a design from a design engine the name of the design on top of the objecteditor gets a green background with a (by default) closed lock. For sure you can make some changes by unlocking the design, but as I said already it will not infect the baseline design. As any design engine starts from the baseline design, this might be the cause for the original issue you reported. If you want to continue working on a specific design from a design engine, you need to make it the baseline-design first: Go inside the design you want to make baseline (doubleclick -> green bar) and "Save Current Design As" a new clean project (without results from the previous design engines). I hope this helps. Best, Carl

Hi Carlos, Please make sure, that you have created an evaluation parameter which takes a value from a result file (@ 5:00 of the video tutorial) and make sure that you have set this parameter as an evaluation in the sobol settings (@6:54). If the parameter has a fix value and no reference like: Runner.getResults().getTable("cd.csv").getElementAt("cd") you may get the Message "There are evaluations that are not influenced by any design variable.". CAESES checks every dependency before running software-connections in an optimization algorithm. It is to save resources. If there is no reference to any value from a resulting file of a software-connection, this application will not be executed. Best, Carl

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

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.

Hi David, You are on the right track 🙂 In the "Advanced" Edit Menu of the input Arguments you can set the "Is Hidden Condition". You need to make sure that each time you insert a first input value, your editor gets refreshed. So for your first input argument you toggle the "refreshes editor" button (see screenshot). For the following dynamic input fields you can reference the first input value for example with this.getARGUMENTNAME() and add a condition to it. I will attach a simple example feature definition here for you to test. DynamicArguments.fdf I hope this helps. Cheers, Hedi

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

Hi Rizuan, On our webpage please go to Support > "Your Licenses" Once logged in, please check the status of your license. By clicking on the manage button on the right side, you may have the option to release a hanged webfloat slot. Please let me know if this resolves your problems. Cheers Ceyhan

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

Hi Nikolas, 1) I can suggest you a work-around; Please check the attached pictures and project; What I have performed is creating a BRep out of the entire exported geometry and then to each BRep I have added an "Remove Faces" operation where I kept only the specified colored surfaces. I have disabled the scope export line inside the fsc file and then included a few lines for the export of the specific surfaces. Please let me know if this resolves your problem. 2) Can you please be more specific about the "cracked" file? Do you refer to the main stl file within which exists the data of the other extracted stl files? Cheers Ceyhan axialfan_sample.cdb

Hi Nikolas, The naming for the "STL (Extract Colors)" export should be as follows; <base name provided for exported stl>+"_"+<color name>+".stl" In the example provided, I gave a name "fanExported.stl". So the base name would be "fanExported" For the blades, during the blade creation process I have assigned a user created color with a name "w_blades" As a result the stl file for the blades ends up being "fanExported_w_blades.stl" To conclude, if you would like to change the stl file names for the exported geometry, one has to modify the assigned color names. I think the Tutorial; Geometry Modelling > BRep and Solids refers to color assignment to operations. Please let me know if you have further questions. Cheers Ceyhan

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

Hi, Sometimes diagrams with important data are available only as graphics files (e.g. after scanning from a report or upon exporting from a pdf-file). CAESES / FRIENDSHIP-Framework can be quickly utilized to read off data from diagrams with high accuracy. To do so, import the graphics as an png-file within a "GL Picture Frame" (1st step). Upon setting the scales of abscissa (x-axis) and ordinate (y-axis) (2nd step) you can readily position a point in your diagram and get your x- and y-coordinates (3rd step). (You may want to use such a point to check the level of accuracy.) Furthermore, you can approximate a graph with a curve, say a B-spline curve (4th step) or interpolate it (5th step). Using the curve representation you can "inquire" the y-value for any given x-value (6th step). The attached fdb-project illustrates the work flow for an imaginary speed-power curve. In addition to using CAESES / FRIENDSHIP-Framework to extract data points from diagrams, you can follow the same approach to replicate a lines plan of a boat, yacht or ship, circumventing classic digitization. Offset data are thus produced effectively. Nice side effect is that you can adjust selected points, for instance to improve accuracy of lines remodeling and "repair" apparent outliers. Kind regards, Stefan ExampleDiagram.zip

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

Parametric models are typically built from various geometric or non-geometric entities, e.g. a projection curve depends on the curve that is going to be projected and the surface it is supposed to lay on. In most programs the user creates the desired object first (in this case the projection curve) - and is subsequently asked to supply the necessary objects (surface, curve and possible projection direction) until the configuration is complete. In CAESES/FFW missing information is indicated by a * next to the required attribute and you can set the relationship via drag and drop or typing. However, if you have selected a surface and a curve already when creating the projection curve, they will be automatically associated to the attributes. Note: Whenever the selection set fits to a creator called, the attributes will be set immediately. For every object you will find a list of available creators in the type documentation.

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

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:

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"

Dear Matheus, you are absolutely right. Indeed, complex models can benefit a lot from parallel computing. Unfortunately, up to the latest CAESES 4.x no such option is available (except for the settings referring to multiple external tools running in parallel during an optimization that you mentioned). However, one of the mayor changes of our upcoming release CAESES 5, is in fact the full parallelization. If you are particularly interested in this feature you can stay tuned via our newsletter here: https://www.caeses.com/news/newsletter/ P.S: Often times it makes sense to take a closer look at what particular part of your geometry slows down the update -- you can use the profiler (go to help > start profiling, then trigger a model refresh, i.e. by changing a design variable and then go to help > stop profiling) to get statistics of the most time consuming objects in your model. Cheers, Heinrich

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