You may remember that I wrote about parallelizing my code well over a month ago. Funny thing about that: It’s almost September and this approach never ended up yielding any Actual Results. So, here’s what I did:
Now, it’s working great. I had maybe three minor bugs, and now it’s expected to run completely through by next Friday.
It’s funny to think that I spun my wheels for over a month trying to do things that would least impact other users and speed up my own code’s execution, when I would’ve been ahead to have just done what I’m doing now, as dirty as it feels.
There’s probably a lesson in here about the benefits of not parallelizing code, or in “playing the game” as stated by whatever software you’re using (that is, by not being an uncommon use case for the code). Hell, maybe there are a few. But, I don’t really find any of these lessons (assuming I’m learning them) very satisfying. I guess I feel like that, if I were using a “better” base for my calculations (say, python >=2.6 numpy, sfepy, a working mesher and a half-decent model builder) that I would’ve been miles ahead despite the much greater initial learning curve and barriers to setting up a working system. Plus, I could’ve avoided the ARSCputers. I mean, I couldn’t even install Node.js on them. Hard to say.
I guess things from the last month+ aren’t totally a wash production-wise. I did figure out how to extract the apparent k-value from the temperature time-series data. We’ll see what happens after I properly git everything (since I can’t push to github from the ARSCputers either for some reason).