Using Octave/MatLab functions to set border conditions?
I have a question and hope that you can help me.
My company is searching for a software to calculate heat flux
through a concrete wall of a tower due to solar radiation.
(will be 2D-model in the first case)
We were doing one such calculation before using Autodesk Multiphysics (Algor).
But since there is no possibility to automate data in- and output and do other scripting stuff
we have to switch to another software or I will go crazy because of all that repetitive GUI clicking :)
While searching for different software packages to compare
OpenFOAM caught my eye, because it looks quite complete and is open source.
In our problem the solar radiation and ambient temperature are used as border conditions
and we have Octave/MatLab functions that return these values.
Is it possible and easy to use these returned values as input for OpenFOAM?
Pseudo-code maybe would be
include "octave.h" or
border_condition_wall(time) = MATLABFUNCTION.solarirradiation(time, date, weather, airmass)
First, pythonFlu initially comes with the automation capabilities you are looking for (you can easily bind corresponding pythonFlu based code with your specific application, look).
Second, Python has a lot of libraries that could easily satisfy all your "Matlab / Octave like" needs (NumPy and SciPy, for example).
And, might be, the third, there is a living example who uses pythonFlu in the way you are interested in.
Thanks for your answer. pythonFlu looks quite interesting. I also read a presentation about pyFoam. What is the difference between the two?
But since I usually write C++ code I would rather use it instead of Python to glue OpenFOAM to Octave/MatLab. Has someone of you ever done this and can show me a small piece of code how this could be done?
You said, that Octave so suitable for you, that you are going to invest your time and energy for embedding it into the target C++ solver.
Now, imagine, that the OpenFOAM solver itself could be written completely in Octave. Would you still like to implement your solver in C++?
And this is the pythonFlu case - "solver as any other user specific code could be written and communicated directly in Python without any loss in clarity and performance"
Also, imagine, you need to add some automation features in your OpenFOAM calculation environment. Something like, parameter variation, conditional running and so on. As we know, Octave will come first in your mind (you are going to use it at any case). Ok, then you decide to implement such stuff through Octave - that is PyFoam case. I mean, that you still have two different beasts - C++, for solver implementation and Python, for its automation.
By the way, while I were trying to find out the proper answer on your last question I have bumped on the list of the existing Octave front-ends, namely Perl, Tcl and Java. I started to wonder, why there is no Python among them? Actually, I have found Pytave, but it seems has been abandoned long ago (the latest modifications were done at 2008). So, I started to wonder once again, why?! The answer was actually straightforward -
Existing NumPy and SciPy libraries cover all aspects of Octave functionality and made it no sense to invent any Python Octave front-end at allSo, if you would like to use something as flexible as Octave, but are going to base your solver implementation on OpenFOAM ... you know the right solution ;)
Thanks for the explanation, I get the difference now :)
pythonFlu seems to be a good solution for some situations,
but I am still not convinced... :)
And since we need this in our company for important calculations
I would rather stick to the well-known and mature OpenFOAM
and our working Octave-functions.
Well, until now there is no answer from people that could give some lines
of C++ code showing how difficult or easy it is to glue OpenFOAM to MatLab
or Octave. Maybe my question is not clear enough...
I need to set transient border conditions, and in the end I do not
care about how these are set, I just do not want to do it manually :)
And I do not want to completly rewrite a solver until implementing
transient border conditions is a really really easy job. Is it?
My idea was just to call a MatLab-function from a C++ program,
which is quite an easy job to do. But is it easy to put the
returned values into into the solver? Or is this not
possible at all?
I read about the possibility to use
to use transient border conditions. Well, this seems to be quite easy.
So I got an idea and please tell me if this is completly nonsense:
I have to set border conditions on the outside of a 2D-circle.
This simulates sunshine onto the tower. The circle has to be
discretized. So I will subdivide it into 1° pieces. Each of
this subdividions will receive different and transient border
To achieve this I will use Octave and OpenFOAM separatly.
An Octave function will write the mesh-file using for-loops creating
the 360 Physical Surfaces and assign their names, e.g. Face001 - Face360.
I am not familiar with blockMesh's file format, but thinking of gmsh's
syntax seems this is quite an easy job.
And the Octave function calls the sun-position-function and writes the
results to 360 different text files,e.g."Face001.dat" that are called
by that are called by using
and so on...
Well, I need a second opinion - does this sound like complete nonsense???
Or is it easier to glue OpenFOAM to MatLab/Octave directly?
Im not sure if this will help at all, but here goes.
My programming skills in anything other than octave is limited at best, and thus I've opted to use octave scripts to do the following for me:
1) update gmsh geometry file
2) call gmsh to create mesh
3) call convert mesh to OpenFOAM
4) update velocity boundary conditions
5) call OpenFOAM to solve case
6) read cost function value/s into optimisation script
7) optimise geometry variables
8) loop from 1
This doesnt really "glue" octave and OpenFOAM together, but rather uses OpenFOAM as a tool inside octave. I wont even begin to claim that this is a good way to do things, but its the best I could come up with.
This sounds quite good from my point of view since it looks
like you used octave to script all the way from automated mesh
creation to solving the case.
And since for my case I need about 360 faces to form a circle,
each of them having different BCs, scripting sounds great.
So, if you do not mind, I would really like to see some scripts
you wrote :)
No problem. Send me your email address and we can discuss further.
If you want to do optimisation many consulting companies (ICON, Engys, etc.) use DAKOTA http://dakota.sandia.gov/software.html
Read the post by Paolo Geremia http://www.extend-project.de/compone...=6&start=6#187
(to read you have to register)
Thanks for the info. It is useful to know.
For now I will be sticking to an optimisation algorithm developed at the university (DYNAMIC-Q), If I dont come right I'll look at this as an alternative.
Of course you can do that easier with pythonFlu ! :D
|All times are GMT -4. The time now is 10:43.|