Ruby, Google, GetDP -- or Perls Before Swine?

[pezman]

Ok, I figured I'd move the whole GMESH etc. subtext to its own thread.

I wonder if Google Sketch could be used as a shell for a relatively nice, free simulator, in the following sense.

Suppose that you used a GMESH approach to describing the PJ geometry. It wouldn't be too hard to have Sketch render the corresponding object.

Suppose further that Sketch could then convert the object into a GetDP model (or maybe an OpenFOAM model), and then run said simulation.

Then suppose that Google Sketch could import the results and allow you to interactively view them (i.e. step forwards and backwards through time etc., as with UFLOW).

While Google sketch does have its aches and pains, it seems more capable than GMESH from the point of view that it; (1 has the Ruby scripting built in and (2 is a reflective environment (which is where the ability to convert the geometry to a simulation arises).

BTW -- If anyone would be willing to post an elementary PJ-relevant OpenFOAM model, I'd like to take a stab at running it on my "Grandma LAMP" virtual machine. If I can manage that, then I think I could make a crude web service for PJ simulations (i.e. submit GMSH file and maybe some initial conditions using your browser, get back a result)

[tufty]

Ok, I figured I'd move the whole GMESH etc. subtext to its own thread.

I wonder if Google Sketch could be used as a shell for a relatively nice, free simulator, in the following sense.

Suppose that you used a GMESH approach to describing the PJ geometry. It wouldn't be too hard to have Sketch render the corresponding object.

Yep, SketchUp is much more capable than gmsh in that respect. Pretty pictures a-go-go. You'd probably need to take a parameterised / scripted gmsh .geo file and resave it as a .geo from within gmsh to be able to get anything easily importable, though.

Suppose further that Sketch could then convert the object into a GetDP model (or maybe an OpenFOAM model), and then run said simulation.

If you're using OpenFOAM, there's no need. Mesh the geo file within gmsh, then use gmsh2ToFoam on the resulting .msh, and you're set to go (after setting boundary conditions and all that jazz). There's very little chance of making it so that SketchUp could run the sim, or directly interpret the results.

Then suppose that Google Sketch could import the results and allow you to interactively view them (i.e. step forwards and backwards through time etc., as with UFLOW).

Again, with OpenFOAM, there's no need. You can either export to your favourite viewer (Fluent, etc) or use ParaView directly. ParaView has a couple of little gotchas, but otherwise it's pretty damn capable, and vastly better than anything you're gonna get from SketchUp.

While Google sketch does have its aches and pains, it seems more capable than GMESH from the point of view that it; (1 has the Ruby scripting built in and (2 is a reflective environment (which is where the ability to convert the geometry to a simulation arises).

Well, having Ruby is a handy thing, for sure. But gmsh .geo files are *highly* scriptable if you get away from the pointy-clicky interface, and the meshing tools are very very good. You need to be a bit careful if importing to OpenFOAM, as it wants quads and hexahedrons rather than the default triangles and tets, but that's not too hard to do once you get to know the file format a bit (the tutorials that come with gmsh are handy for this)

BTW -- If anyone would be willing to post an elementary PJ-relevant OpenFOAM model, I'd like to take a stab at running it on my "Grandma LAMP" virtual machine. If I can manage that, then I think I could make a crude web service for PJ simulations (i.e. submit GMSH file and maybe some initial conditions using your browser, get back a result)

There's quite a lot more to it than "maybe specifying a few inital conditions", sadly. You need to specify the solver to use, and a bunch of stuff relevant to the solver (for combustion and / or turbulent flow models this can get *very* complex). OpenFOAM 1.4 has 40+ different solvers "out of the box", of which a good many are of use to us; the ones we want are hard to set up.

If you want a model that can go into OpenFOAM:

Copy one of the tutorial models that grabs your fancy to your run directory, as, for example, reynst_segment. A good one to start with would probably be turbFoam/cavity

Get a copy of gmsh2ToFoam, unzip it in the OpenFOAM source directory applications/utilities/mesh/conversion and build it (cd to the directory and wmake). This is not absolutely necessary, but it makes life a load easier, as the default gmshToFoam ignores the named bits of the model and you then need to go and edit the boundaries file by hand.

Grab the reynst segment model I posted yesterday, mesh it in 3d.

Import the resultant .msh file into the copy of the test case using gmsh2ToFoam <path> <casename> <path_to_msh>

Everything will be all fuxx0red, so fire up FoamX. Open up each of the mesh elements and set the right type. The wedge bits should be set to "wedge", the inlet and outlet should be "inlet/outlet>atmosphere", the walls, dependent on solver, for turbFoam you can probably get away with simple "wall" or "adiabaticWall".

Save the case in FoamX, quit FoamX

Open your favourite text editor and set boundary conditions for the variables by editing the various files you'll find in the <case>/0 directory. While you're at it, play with the controlDict to set start and end times, timestep, all that jazz.

Make a setFieldsDict in the <case>/system directory, you can use this to set values based on either cell sets or on boxes. cell sets in the model I posted are "pot_volume" and "stack_volume". If you're running OpenFOAM 1.3 you can build funkySetFields (from the wiki above) for fully customisable value setting (I'm running 1.4, it won't compile for me, bah)

Here's the relevant setFieldsDict I used for the stuff I posted earlier, the fields set here will not all be relevant for turbFoam (I was running XiFoam, setting fuel fraction ft, pressure p and velocity U)

Code: Select all

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  1.0                                   |
|   \\  /    A nd           | Web:      http://www.openfoam.org               |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/

FoamFile
{
    version         2.0;
    format          ascii;
    root            "";
    case            "";
    instance        "system";
    local           "";
    class           dictionary;
    object          setFieldsDict;
}
defaultFieldValues
(
	volScalarFieldValue ft 1e-8
	volScalarFieldValue p 101325
	volVectorFieldValue U (0 0 0)
);
regions
(
	cellToCell
	{
	    set pot_volume;
	    fieldValues
	    (
	    	        volScalarFieldValue ft 0.16
			volScalarFieldValue p 50000
			volVectorFieldValue U (0 0 5)
	    );
	}
	cellToCell
	{
	    set stack_volume;
	    fieldValues
	    (
	    	        volScalarFieldValue ft 1e-08
			volScalarFieldValue p 101325
			volVectorFieldValue U (0 0 10)
	    );
	}
);

Run setFields to make this lot current. setFields <path> <case>

Now run your solver. Assuming turbFoam, turbFoam <path> <case> and wait.

Easy, no?

Simon

[pezman]

The idea is that the web app would wrap things like solver selection and keep the user from worrying about it. Solver selection seems like a boiler-plate kind of thing, so I think that even the fanciest back-end architecture could be wrapped such that the user doesn't need to bother with details like solcer selection, ssequence of operations etc.

I guess that I'm leaning towards a Sketch Up/GetDP approach since it would be the easiest to support in a Windows environment and GetDP can apparently directly interpret the gmsh stuff and the results are in clear text that should be easy to display.

The process that you described is a little more than I'm willing to tackle at this point -- I'm a big believer in applied laziness.

I guess that the first step would be to see if I can figure out how to do a 1D Euler simulation using GetDP ...

[tufty]

The idea is that the web app would wrap things like solver selection and keep the user from worrying about it. Solver selection seems like a boiler-plate kind of thing, so I think that even the fanciest back-end architecture could be wrapped such that the user doesn't need to bother with details like solcer selection, ssequence of operations etc.

Well, it's boiler plate in certain respects, but a lot of the magic comes from the initial conditions. You could certainly put reasonable defaults up for a given solver's variables (or, at least, a validly formatted set of data) by cribbing from the FoamX source for each solver; that's all that FoamX does, really.

I guess that I'm leaning towards a Sketch Up/GetDP approach since it would be the easiest to support in a Windows environment and GetDP can apparently directly interpret the gmsh stuff and the results are in clear text that should be easy to display.

Fair enough. Personally, I couldn't care less about a windows environment, anyone stupid enough to give their money to MS for a sub-par system deserves a hard time :)

The process that you described is a little more than I'm willing to tackle at this point -- I'm a big believer in applied laziness.

Oh, so am I. Very much so. Laziness is good. The problem as I see it is that th tools we're talking about here are so powerful, and so complex, that there's no way to "wizard away" the hardness. You really do need to understand the tool, what it does, and why. If not, your mixtures fail to ignite, or stuff goes out of bounds, or...

That doesn't mean the tool itself needs to be *hard* to use, as such, just that you can't hide the complexity.

On a related note, I found this earlier : http://openfoamwiki.net/index.php/Contrib_gmshFoam

Simon

[pezman]

I guess that the prospects of re-building the damn thing makes me cringe. It's fine if it works, but when it doesn't, it's often a pain to hunt the problems down and kill them with authority.

As far as I know, the "Grandma LAMP" virtual machine does not have the required development tools. I suppose that I could install them, but my grandma might object.

Don't get me wrong -- I actually like XUBUNTU quite a bit and I don't mind doing some development, but all this Foamy stuff seems like too large an initial step.

For a 1D simulation in air using heat for the ICs rather than attempting to model combustion (i.e. a UFLOW type simulation), I'm hoping that the setup should be pretty straightforward.

Hey, I did some looking into Ruby functional programming, and that took me to some unrelated sites that happend to have some stuff which interested me. One other thing that I like about Javascript is the JSON stuff. I found some "JSON to Ruby" references, but have't run across a native JSON-like mechanism in Ruby. The fact that JSON is layered right on "eval" is just so elegant. I'll have to look at a comparison of the two languages. They're both pretty cool -- I just don't have enough Ruby experience (or Javascript experience, for that matter) at this point to favor one over the other.

[tufty]

Hey, I did some looking into Ruby functional programming, and that took me to some unrelated sites that happend to have some stuff which interested me. One other thing that I like about Javascript is the JSON stuff. I found some "JSON to Ruby" references, but have't run across a native JSON-like mechanism in Ruby. The fact that JSON is layered right on "eval" is just so elegant. I'll have to look at a comparison of the two languages. They're both pretty cool -- I just don't have enough Ruby experience (or Javascript experience, for that matter) at this point to favor one over the other.

Rails has /uses a JSON library, lets you marshall stuff in and out over JSON. About the only downer is that JSON doesn't handle dates natively, I think, although I've not done much with it. Ruby object marshalling is pretty easy to do, and if you're talking ruby-ruby, it's often easier to stick to the out-of-the-box ruby stuff as opposed to bolting more stuff on.

http://json.rubyforge.org/ for one json implementation

The joy of truly dynamic languages like ruby is that *everything* is an object, from the class structure to the *functions of the language itself*.

What this means is that distributed programming gets *really* easy. Wrap up an object and send it to a server (which only needs to be a demarshalling stub, can be as few as about 10 lines of code), and you're done.

> 15 years ago, I was doing stuff like this in C++ on OS/2, *thousands* of lines of code to do the simplest thing. Even later, when I discovered ObjectiveC and NeXTStep, it was kinda tough. Ruby is beautiful in ways that are really hard to grasp, but almost impossible to live without once you're used to them

Yeah, I like ruby

Simon

[pezman]

So I had Ruby navigate IE to the site ...

I figured I'd take a closer look, what with the celebrity endorsement and all.

Featurewise, it's a lot like Javascript in several respects. The syntax is a little more elegant. I haven't run into anything (yet) that made me feel like my pre-Ruby life has been a complete waste thus far.

... except maybe the WEBrick stuff, which is very, very cool. I wonder if I can write an OPCXML-DA server using it.

[tufty]

Featurewise, it's a lot like Javascript in several respects. The syntax is a little more elegant. I haven't run into anything (yet) that made me feel like my pre-Ruby life has been a complete waste thus far.

... except maybe the WEBrick stuff, which is very, very cool. I wonder if I can write an OPCXML-DA server using it.

Webrick is pretty groovy, yes. I wrote an internet micropayment system using premium rate SMS based on it last year. Even allowing for the fact it has a ruby server and a phat database behind it, all accessed through ruby, it can handle 400+tps on one server alone. It can scale to as many servers as you want, too.

I could hav done the same thing in any other language, of course, this particular application worked on the basis I'd built the year before in Perl. the point is that the ruby stuff is clean and maintainable, and it was easy to do.

This is the sort of thing that makes me love ruby, though : I just wrote a rollout system (based on capistrano) for my brother's website, which takes templated html, generates links, headers, footers, image tags and some funky javascript crap (lightbox 2), resizes the images he dumps into my subversion repo, and rolls the whole thing out to either the test server or his live box, incorporating "rollback in case of failure or massive fuckups". 73 lines of code, total. Only 52 of those are actual code, the rest are blank or comments. half an hour's work, and rollouts now consist of one line in a terminal.

Code: Select all

cap deploy [LIVE]

I think you've been missing blocks, you just don't know it yet. Blocks are wonderful.

Simon