Developing a simple program to solve the diffusion equation

[J77]

Hi there,
I'm looking for an algorithm which describes the numeric solution to solve the diffusion equation (1D or 2D).
I've taken a look on some textbook such as Hamilton and Henry ones but I didn't find a simple solution.
anybody knows about it? Where can I find what I'm looking for?
Thanks.

This thread has derailed nicely...

Perhaps the simplest answer to the OP would be to look up finite difference and finite element schemes, for the 1D and 2D problems, respectively.

(This is what Morbius explained in the original reply. However, I've never heard the term "zone" w.r.t. FEMs.)

 

[mheslep]

It was NOT achieved by power and real estate efficiency which is why I jumped on you for that.

Those were MINOR considerations, if ANYTHING.

No. Power may not have been the explicit concern of the user, but power efficiency is tightly coupled to the realizable performance of any large machine today; its not just a nice to have feature any more, obviated by access to dedicated megawatts, acres of floor space, tons of cooling equipment, or even money to burn. Two reasons: 1) HEAT limitations at the CPU and board assembly level brought on by the use of large clusters of ever increasing IC fabrication densities, and 2) local delivery of electrical power (1000's of Amps switched in nanoseconds) to same. If one pops the hatch on the large machines you find they are substantially power distribution and heat removal by volume with some computing thrown in. Modern computing hardware has reached a point where it does not scale further w/ out attention to power efficiency.

 

[Morbius]

I think that it is you who is being the STUPID one here. Open a book on Monte Carlo methods and you will see that it is for solving INTEGRALS! Guess what? That equation you have been solving all of these years via Monte Carlo is an INTEGRAL equation - did you realize that?

Q,

Actually the equation that is being solved; the Boltzmann Transport Equation is an
Integro-differential equation. It has BOTH integrals [ due to scattering ] and derivatives
[ due to the transport terms ]

We solve statmech problems because we can write the expectation value as an INTEGRAL. Metropolis et al. did the same kinds of things that I AM, solving INTEGRAL equations for the equation of state of a gas in their landmark paper. You say that they the ability for MC to solve integrals "came later" - you truly do not understand the process, you think that the founders actually would be as STUPID as you are?

I don't have a quibble with your use of MC methods for solving your statatistical mechanics
problems. However, I VERY CLEARLY explained to you where the parallelism is broken.

The parallelism is broken in the TRANSPORT part of the Monte Carlo - that's the part that
has DERIVATIVES.

Your problem is only an integral problem - therefore you don't have the same coupling as the
transport equation does.

When I clearly explained where the parallelism broke down; due to the transport; you applied
my statement of the limitation to your problem when you stated:

However, I'm a bit perplexed that at the same time you question that a statistical mechanical ensemble
can be sampled INDEPENDENTLY via MC...when I have been doing that for years - infact, I am
running a highly parallel statical mechanics simulation via MC on many processors in parallel as we
speak, yet you say that's impossible! What am I to think here?

In the above QUOTE; you stated that I claimed what you had been doing was impossible -
"...yet you say that's impossible! What am I to think here?

Show me WHERE I stated that sampling integrals by Monte Carlo was impossible!

I was VERY CLEAR in my description above that what breaks the parallelism is the
transport of particles among processors. That is due to the TRANSPORT part of solving
the integro-differential part of the Boltzmann Transport Equation.

Where did I say that one can't sample statmech integrals in parallel?

What you did was a classic "stawman" - you mischaracterized what I said - and then proceeded
to dispute it.

THAT'S the part that I find stupid.

BTW - the processors in Blue Gene/L are PowerPC 440s - but "440" is a model number

It doesn't mean 440 MHz as you ERRONEOUSLY claimed above in your statement:
"I could run my code on 2000 cores of a BG/L (440 Mhz, etc.)

The PowerPC 440 processors in Blue Gene/L do NOT run at 440 MHz.

You probably think that you can bully others into accepting your retarded views, from what I have seen of your interactions with others in this forum.

I'm just challenging ERRORS! You've promulgated an entire string of errors; starting with
claiming that Monte Carlo will beat deterministic methods for solving a reactor problem, which was
the original poster's contention...all the way up to mischaracterizing what I said for your "strawman"
arguement.

The original poster asked a question concerning nuclear reactors and the neutron transport therein,
which you answered INCORRECTLY. When called on that you "morphed" the discussion into
how Monte Carlo parallelizes for statmech problems. However, your experience solving some trivial
statistical mechanics problems doesn't apply to the nuclear reactor transport problem which was
under discussion in this Nuclear Engineering forum.

It's not "bullying" to CORRECT ERRORS! If you pursue a career in science; get used to people
correcting you.

Dr. Gregory Greenman
Physicist

 

[Morbius]

If one pops the hatch on the large machines you find they are substantially power distribution and heat removal by volume with some computing thrown in. Modern computing hardware has reached a point where it does not scale further w/ out attention to power efficiency.

mheslep,

The Blue Gene/L and ASC Purple machines are air cooled - with ducts in the floor to force cooling
air through the machines.

The air blowers for the cooling systems is one floor below the machine floor in LLNL's TSF.

I stood in the air stream that goes to cool Blue Gene/L and Purple; and it was like being in a
hurricane.

If you look at a picture of Blue Gene - the sloping sides were dictated by the design of the cooling
air flow:

https://asc.llnl.gov/computing_resources/bluegenel/index.html

Dr. Gregory Greenman
Physicist

 

[Morbius]

This thread has derailed nicely...

Perhaps the simplest answer to the OP would be to look up finite difference and finite element schemes, for the 1D and 2D problems, respectively.

(This is what Morbius explained in the original reply. However, I've never heard the term "zone" w.r.t. FEMs.)

J77,

"Zone" is used more with finite difference equations; the term "element" is used in finite element.

Many times one speaks of a "mesh" being used to discretize the space. The points where the
mesh lines cross are called "nodes". The little volumes that make up the mesh are called "zones".

Dr. Gregory Greenman
Physicist

 

[Morbius]

See? That wasn't so bad right? You see, the seminal work makes use of the stochastic method, via the Metropolis acceptance function, of sampling an ensemble of configurations. This is how everyone else in the world knows the term "Monte Carlo".

So I have Metroplis and Teller on my side here - are you so arrogant as to say them wrong too?

quetzal,

NOT AT ALL You certainly DO NOT have Metropolis and Teller on your side.

What you have obfuscated here is what type of "Monte Carlo" technique one is talking about.

We are not talking about Monte Carlo methods in general. We are talking about a particular application
of Monte Carlo to solving the neutron transport / diffusion equations and your ERRONEOUS response
that that particular application parallelized trivially.

One can use a "Monte Carlo" technique to do integrals by sampling an integrand. That type of
"Monte Carlo" does parallelize trivially because all one has to do is sample from a function; and all
those calculations are independent, and hence parallelize trivially.

However, your statement in Post #6 to a previous poster was:

the real power of parallelization comes with higher dimensional diffusion. in which case, a more efficient way of calculating diffusion is through Monte Carlo integration (since the error scales as 1/sqrt(N) rather than with the dimensionality), which indeed parallelizes trivially. for a 1D case i can't see any reason why you would parallelize.

In the above, you are advocating using a Monte Carlo technique to solve the neutron diffusion equation.

It's the Monte Carlo technique for solving neutron transport or neutron diffusion that does not
parallelize trivially; for the reasons I cited at length above.

In Post #19, you chastise me for limiting my discussion to the neutron transport problem:

It sounds like you are focusing on a very particular type of problem - neutron diffusion in some fissile material. However, keep in mind that if one was, for example, solving for a statistical mechanical observable, then doing the trivial parallelization where each processor handles a separate (indepedent) sample is appropriate

For Heavens sake, of course I was "focussing a very partucular type of problem - neutron diffusion";
because that's what we were talking about back in your Post #6.

I agree that one can trivially parallelize a Monte Carlo technique for sampling a statistical mechanical
distribution - but that doesn't solve the neutron diffusion problem - which is what you claimed could
be done trivially in Post #6.

So - it's a "Catch-22". Either the "Monte Carlo" method you recommended in Post #6 was a trivially
parallelized statistical mechanical sampling method; in which case you are WRONG in Post #6
because statistical mechanical sampling doesn't solve the neutron diffusion equation.

Or, in case you meant "Monte Carlo" to mean a method of solving the integral-differential neutron
transport and / or diffusion equations; in which case you are WRONG again because such
algorithms don't trivially parallelize.

Either way - you have OBFUSCATED what a "Monte Carlo" technique is, and how it is used.

Dr. Gregory Greenman
Physicist