Jump to content

Search the Community

Showing results for tags 'CFD'.

The search index is currently processing. Current results may not be complete.


More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • CAESES®
    • General Modeling
    • Software Connections
    • Variation & Optimization
    • Post-Processing
    • Feature Programming
    • Installation
    • Miscellaneous
    • Ideas and Suggestions
    • FAQ

Categories

  • Articles
    • Forum Integration
    • Frontpage
  • Pages
  • Miscellaneous
    • Databases
    • Templates
    • Media

Blogs

  • Mr. Arne Bergmann's Blog
  • FSYS DAEHWAN PARK
  • Mr. Arne Bergmann's Blog
  • Rel 3.1
  • Joerg Palluch's Blog

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 7 results

  1. Hello everybody! I have a few days on the openfoam connection, and searching through the forum about it. I'm trying to follow the "Sduct with OpenFOAM" tutorial, to get a grasp of it. I got to the step 10 (triggering the first run). The "stdouterroroutput.redirect" file states the error: "fileName::stripInvalid() called for invalid fileName complete/path/to/Runner For debug level (= 2) > 1 this is considered fatal". This goes for: Exec : blockMesh -dict system/blockMeshDict Exec : snappyHexMesh -overwrite Exec : simpleFoam But in none of these files is there a filename specified, so I got no idea what's happening. Other question: The tutorials and video talk of these "software connector" that has been configured before, is there a tutorial to learn to configure this file? Should I install Helyx-os for handling these files? Or I can do that from CAESES? Cheers, and thanks for your time. Xavier
  2. Hi folks Please find attached a CFD-ready, fully parametric propeller geometry (optional with shaft and PBCF). Modeled in CAESES. See the marine section for more information about propeller design. It bases on the model which Daehwan, one of our Naval Architects, posted a while ago: http://www.friendship-systems.com/forum/index.php?/topic/201-propeller-boss-cap-fin-pbcf-modeling-practice/ I made a few changes to make it more user-friendly. First of all this project provides 4 CFD-ready Solids which you can find in the baseline scope. In order to export one of them as a STL file, select it and go to "FILE > EXPORT > STL" or type into the console ".exportSTLExtractColors()" (or similar). STL_Propeller_Only: This is just a watertight propeller with a hub. In order to change the fully parametric blades go to "1_bladeModeling > 2_geometry > 2_blade". There you can find the functions and the blade engine. STL_With_Shaft: This Solid consists of the same propeller and a simple shaft.STL_With_Cap: Additionally to shaft and propeller you can find a propeller cap which holds the fins in the next STL file.STL_With_Fins: This is the complete geometry which you can see in the first picture.A few words to the parameters: You can find the different sets of parameters in "1_parameters" in each Modeling-Scope.I added a documentation to every parameter.You can find one parameter directly in the Baseline-Scope: RBlade (propeller blade radius). This parameter is used as the global scaling parameter. If RBlade=1, every parameter in the project keeps the exact value which you can see (and measure) in the 3dView. By changing the propeller blade radius the whole geometry scales accordingly. Each parameter will keep the initial value in the ratio to the RBlade=1. [Project File edited 20.10.2014] STL_Propeller.fdb
  3. Hi All, Recently I wanted to investigate the use of OpenFOAM for CFD calculations for a model built in CAESES and perform an optimization at a later stage. Although the OpenFOAM is a C++ library meant to be run in Linux systems, I wanted to test the configuration on my Windows pc and I found this compiled OpenFOAM 2.3 version available. After installing the software as instructed I had to change a little bit the configuration of the software connector in CAESES. Basically, I called the mintty.exe terminal application and run a modified version of the Allrun.sh shell script, as demonstrated at the ahmed body sample. You can find attached a picture of the LocalApplication and its arguments, the modified shell script Allrun.sh and the modified project file of the Ahmed Body sample provided with CAESES installation. Please notice that I have configured the OpenFOAM calculation to run on a single processor and deactivated any parallel computing, because of my restricted resources, but you could easily restore that back. I had also to change some points in the RunFunctions file located in /opt/OpenFOAM/OpenFOAM-2.3.x/bin/tools and you can find attached this new file too. If you are interested in learning how to manipulate OpenFOAM or try some simple simulations on your windows machine, you can give it a try. Cheers, Ilias. ahmedbody.fdbc Allrun.zip
  4. Shipflow is being unable to create offset during the basic running of shipflow. "xoffgen.exe stopped working" - message is showing. But I can't figure out the problem of my iges file. Why is it occurring? Any help please?
  5. Hi together, Please note that CAESES can be utilized as an OpenFOAM GUI (Graphical User Interface). There are free academic versions of the CAESES pro edition for students and PhD students as well as trial licenses with flexible time frames. There are also special editions for small companies, start-ups and freelancers. Compared to other tools in the market, CAESES is good at automation, i.e. if you already have an existing OpenFOAM setup and you want to analyze design variants of your product, then CAESES might be a perfect choice. Especially, if geometry variation plays a major role. In contrast to that, a tool such as HELYX-OS might be a better choice e.g. if you would like to set up an OpenFOAM case from scratch. Here are some CAESES-specific offers: Conveniently configure and manipulate template files (e.g. controlDict or any other ASCII file) in the GUIChange your geometry design and trigger OpenFOAM with a single mouse-click for analysis (i.e. streamline your design process / automation)Use your individual result values such as pressure loss or homogeneity for an objective function in design studies and shape optimizationsPostprocess your simulation data (streamlines, contour plots etc) Here is a video that shows some of the features in CAESES. Cheers Joerg LAST UPDATE FEBRUARY 2018
  6. 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!
  7. Hey, attached is an example of a vertical axis wind turbine, modeled in CAESES. It is fully parametrized, so that an optimization with an external cfd tool can easily be executed. The shape can be varied from straight blades up to blades that are twisted around the vertical axis (helix). The helix shape helps to minimize the effects of uneven distributed forces along the axis and during the rotation. As a result the VAWT will oscilate less which makes it more robust. Further design parameters: pitchcambercamber positionchord lengthradiusmid radiusI created a simple cfd calculation with STARCCM+ to show some post processing functionalities. Have fun with the model cheers vertWind_forum1.fdb
×
×
  • Create New...