/sci/ - Science & Math

What the hell are you simulating? The longest I've had programs run was when solving some NP-hard problems on moderately sized graphs, and that only took about 2 or 3 hours.

>tfw thermal paste crystallizes on day 12.

>>5199176
by now Id've just put the whole computer in a minifridge or something. The hell are you running anyway? or is your computer just complete garbage?

>>5199176
>That feel when you look back at your model in mathlab and find an error/infinite loop after a week running

It's a program stimulating interaction in a population through bayesian updating over a parameter space of probabilities an standard deviations.
This time, my advisor told me that he wants the difference between the min value and max value to be .01. This becomes hard when the consumers in the population already have a high ass precision.

>>5199217
Nah, it's printing out shit and it is making SOME progress

>>5199211
It's a dell inspiron(lol poverty).
So yes, it is complete shit.

>>5199254
Not to say that was a bad idea, but there's a LOT of performance loss for every print (you can easily see that with some simple code), so I hope you are not printing every iteration.

>>5199176
did you use "for" or "while" loops?

if so, kill yourself

That feel, bro.

My recent java project is doing it right now. It's just printing the same thing over and over again. It's been going on for about a week, it just won't stop. Guess I broke the processor with so many lines of code, haha. Profs probably gonna deduct points for being late, but w.e.

>>5199278
yes faggot, how else am I suppose to work over a fucking parameter space?

>>5199272
....
Shit. I guess I should stop and have it print at every 10000 iteration?

That's going to cause condensation in your computer.

>>5199282

>suppose to
>suppose
>"to be suppose to"

Are you one of those monkeys that write "would/should/could of" too?

>>5199295
oh boy it's you

>>5199298
*its

>>5199303
actually it's "it's"
it's is the conjugation of it is
its is the possessive form

>>5199282
>matlab
>for loops
failed so hard.

Vectorize them codes or at lease use parfor or mex files or both

>>5199304
>vectorizing a while min(x)-max(x)>.01 line

>>5199306
flip those actually

>>5199305
>it's is

>>5199303
it is you knob

>>5199305
Ninja'd me!

>mfw people are arguing over grammar and spelling in a thread about math coding and pc cooling.

You guys are just dicks. /b/ is rubbing off here.

rewrite it in C++

>>5199324
>mfw you think that /b/ is literate.

I think you mean /lit/

Last month I ran my main research code (written in C++) roughly 900k times to cover a 3D parameter space and generate a set of data for further simulations. This is a normalized distribution of wall-clock time per run completion.

So with a most probably completion time per run of ~4mins, I had to use my university's super cluster. I load balanced these serial runs across many cores to create a task-parallelization to get this shit done in human time.

It took one chunk of 11400 cores for 6hrs, then 3 chunks of 5400 cores for 6 hrs to complete all ~900k runs, totalling roughly 185k CPU-hrs.

Waiting in the cluster's queues while assholes try to put on way too many jobs gets annoying as hell.

Also, I did this entire set computation twice and still have allocation left for another 2 sets of 900k if I want.

That lattice qcd simulation feel.

>tfw CASTOR takes over two fucking hours to serve up 3 files and you still get the wrong pion lifetime

I don't usually have an issue if I can parallize my work well. I mean, your academic license should scale to 12 local cores, plus the GPU. We have an in-house code for tomographic-reconstruction of velocimetry data, and of course we have a deforming, domain-shifting multi-grid method that eats up FFTs like a mad cunt. Going from raw images (usually on the order of 5 GB/s of data collection) to [u,v,w] data can take the better part of a day running on 12 cores, and running the FFTs on the GPU. Usually that's all done by overnight on my desktop.

Computational problems can be pretty large - especially when you have deforming mesh problems. They can take a couple days. Of course, when you get to big problems (implicit large eddy, or something of that manner) we have to start making use of the local super-computing facilities. OP: are you sure your code is properly optimized, for your machine, and if so why have you not simply uploaded a batch file to whatever local cluster is available?

>use cluster of 700 eight/twelve core CPU
>occupied at 99.8% virtually always
>want to run a permutation testing algorithm
>expected run time for about two days
>it's in the cue for more than a week
>finally gets submitted
>error in the script after 15 hours of run time
>have to start all over again