Archive for September, 2009

comment on friction

Ah, friction, dissipation, entropy production. Life in the non-equilibrium world is so unpredictable…

Your comment: ‘Continuously readjusting non-explanatory models to fit new data isn’t what a science does. ‘ is too optimistic.

I guess by ‘causal mechanical’ you mean dynamical models, and explicitly not regression or stochastic schemes? If so, fitted models like the ones I mentioned are still the best tools available in some noisy physical sciences, I’m thinking hydrology in particular, and older but still used atmospheric subgrid parameterisations.

Nevertheless, you’re right to prefer a dynamical approach where available. I suspect though, as others in the thread have noted, that the system is simply unpredictable at some of the time scales we’d like it to be, and that it might turn out that simple models explain most of the predictable variance.

http://www.willwilkinson.net/flybottle/2009/09/07/flaws-and-frictions/?dsq=17371660#comment-17371660

Advertisements

Leave a Comment

Death Magnetic Rocks

Really enjoying this Album. Takes me back to when Metallica first spoke to me as a teenager. I think Hetfield’s writing is brilliant.

Leave a Comment

custer was a coward

according to a documentary I am watching. It says he tried to take women and children hostage and got fucked.

Leave a Comment

Wrapping modern f90 with f2py

I’ve started wrapping my fortran sph code, with the aim of being able to reuse a lot of code. In particular the second order spatial gradients code is long, and error prone. Python wrapping not only means I can use fast fortran for my real-time 3d fluids code, but it makes testing and verification that much easier. Plotting for fortran was a matter of spitting out ASCII files and writing a script to plot them. Somewhat ad-hoc, and either leading to the code being littered with commented out write statements, or multiple hardly ever used output files being written every run.

I’ve had to remove a lot of the more whizz-bang features, like derived types and assumed shape arrays from the argument lists of the subroutines I’ve ported, but a) this is only a subset of the code and b) it’s not hard to make these changes on neat, tidy, single purpose routines, which are the best candidates for wrapping and reuse in the first place.

Leave a Comment