[erlang-questions] Erlang meets physics

[Jared Kofron]

Hi All,
I've been using Erlang at work for a few years now, and I thought I'd throw my experience out there, as
my application is a little different than what you usually see on the list - I am a graduate student at the
Center for Nuclear Physics and Astrophysics at the University of Washington, and use Erlang extensively
in my work.

In my experience, something that Erlang is really great at but doesn't receive much attention for these days
is managing and interacting with hardware. In any physics experiment of even modest sizes, you wind up
having to keep track of the state of various pieces of equipment, often modify that state, and constantly
interrogate particular values. For example, we might want to change the current in a magnetic trap, turn
that trap off altogether, or simply read back the voltage drop across our superconducting magnet.

So far, I have deployed Erlang in this zone for two separate experiments (SNO+, a large particle physics
experiment in Canada) and Project 8 (a small nuclear physics experiment here in Seattle). Both times have
been great successes, and I have found the reception of Erlang in this market to be great. In general, what
I have done is wrap a hardware management layer with some kind of outside world interface. For SNO+, we
used Webmachine and RESTful control, and for Project 8 we actually conduct all communication
by using CouchDB as a message passing interface.

Physicists are suspicious creatures, but once you demonstrate the feature set that you get for practically
free with OTP, they see the advantage pretty quickly. On top of that, the development cycle for sophisticated
applications can be greatly reduced - more than once it made my group float to the top in terms of meeting
goals.

In short, as far as I am concerned, Erlang has found a new niche in the world of Physics, and I intend to
spread the word as much as I can!

Jared Kofron
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Joe Armstrong]

Great news - spread the word !

Just for the record Erlang programmers numbers 1 and 2 (ie myself and
Robert Virding)
are both ex physicists.

When I lecture I often point out the similarity between causality and
message reception.
You don't know that something has happened until you get a message
telling that it has happened.

(In physics it's a ray of light, or a photon, or something -
forgetting entanglement for the moment)

In computing it's the reception of a message.

As a ex physicist I know that we can't say anything about simultaneous
events occurring
at different places in space-time - turn this into computer science
and the same arguments
apply to things like making sure replicated data is consistent on
remote sites - well you can't
- at least if you want to change it - Brewer's CAP theorem applies -
which for a physicist makes
perfect sense.

Also as an ex physicist I realize that things do actually happen in
parallel in the real world,
so modelling them in a sequential programming language (if I wanted to do that)
is big time crazy - just describe the parallel stuff in a concurrent
language and the program
writes itself. Wait a few years till we have million core computers
and the parallel problems
can be solved 1:1 on parallel computers - and programming simulations
and so on will be
really easy - but don't even think about doing it in a sequential language...

Cheers

/Joe

[Pablo Platt]

How do you interact with the hardware?

Do you use GPIB C libr and wrap it with a NIF?

---

From: Joe Armstrong <erl...@gmail.com>
To: Jared Kofron <jared...@gmail.com>
Cc: Erlang Questions <erlang-q...@erlang.org>
Sent: Tuesday, March 13, 2012 12:34 PM
Subject: Re: [erlang-questions] Erlang meets physics

[Jared Kofron]

Hi Pablo-

My first project was on embedded hardware, and basically consisted of NIFs and Webmachine dispatching.

Pretty fun stuff.  

My current project is a little more involved, but is also pretty interesting:

Right now the bus over which communication takes place is abstracted away by having hardware modules

which translate API functions into their appropriate wire representation and then transmit those representations

over a handle that they have to the correct bus.  

In essence what I've done is taken instruments and buses and given them something like behaviors.  

Hardware can perform read,write,or configure, for example.  So if I want to read the center frequency of a sweeper,

I might say

hp8340b:read(high_frequency_sweeper,<<"cw_freq">>).

which the device module (in this case hp8340b) translates into the GPIB command "OPCW", and based on the

device address (which is governed by the atom in the first argument), dispatches it over a bus handle that it owns

in a state variable via bus:send_query/2.  

At the moment, we only communicate with things over GPIB via ethernet using prologix devices to do the translation

for us - basically glorified telnet - but it gets the job done.  Everything is in a very alpha stage right now for this project,

but it is working really nicely so far.

JK

[Jared Kofron]

Hi Joe-
What a surprise! I had no idea that you and Robert V were both recovered physicists.

I absolutely agree with you re: concurrency in erlang. I find handling the concurrent aspect
of my programs to be essentially trivial in erlang, especially once you leverage the power of
supervision trees.

JK

[Robert Virding]

We used ports. External hardware was a "process" with which you communicated through messages. The asynchronous model fitted hardware very well, at least the hardware in which we were interested.

Robert

---

[Richard O'Keefe]

On 14/03/2012, at 12:47 PM, Jared Kofron wrote:

> Hi Joe-
> What a surprise! I had no idea that you and Robert V were both recovered physicists.

My master's degree was in Underwater Acoustics... There must be lots of us about.
(Can that be why I think Joe is right so often? Nah, surely not...)

[Pablo Platt]

>which the device module (in this case hp8340b) translates into the GPIB command "OPCW", and based on the
>device address (which is governed by the atom in the first argument), dispatches it over a bus handle that it owns
>in a state variable via bus:send_query/2.  

Can you explain how the device module translate to the GPIB command "OPCW"?
Is it pure erlang?
Maybe you can share some code?

Thanks

________________________________
From: Jared Kofron <jared...@gmail.com>
To: Erlang Questions <erlang-q...@erlang.org>
Sent: Wednesday, March 14, 2012 1:43 AM

[CGS]

Hi,

Firstly, I am glad to see physicists getting interest in Erlang.

I see Erlang best usage in physics in few fields from Astrophysics/Astroparticle Physics/Elementary Particle Physics:
1. GRID;
2. integrated in the readout of an array of detectors for atmospheric showers,
but there are few fields in which Erlang still cannot replace C/C++ (or Verilog in some cases):
1. accelerator (high and medium energy) physics (high frequency readout may not be compatible with Erlang, or vice-versa);
2. Monte Carlo simulations (even if it provides nice concurrency and code hot swap, it lacks some quite important characteristics).

There may be some other fields from physics where Erlang may be suitable (except for communications for which is intended), but I am not the person to speak about. Nevertheless, it's good to know Erlang enters the above mentioned fields.

Good luck!
CGS

[Jared Kofron]

On Mar 14, 2012, at 5:21 PM, CGS wrote:

Hi,

Firstly, I am glad to see physicists getting interest in Erlang.

I see Erlang best usage in physics in few fields from Astrophysics/Astroparticle Physics/Elementary Particle Physics:
1. GRID;
2. integrated in the readout of an array of detectors for atmospheric showers,

Very true, these are great test cases for Erlang.  EPICS is a project that accelerator folks wrote a long time ago (and still use and maintain to an extent)

that I think is a no-brainer application for Erlang: http://www.aps.anl.gov/epics/.  It is written in C and forms a distributed data acquisition system.

[Jared Kofron]

Hi Pablo-
The translation is a simple pattern match - locator_to_ch_data(<<"cw_freq">>) -> "CW", which is then transformed into
the final string which is passed over the wire.

If you'd like to take a look at the code it's at http://github.com/kofron/dripline. It's very very alpha, although deployed
in limited production it works quite well.

Unfortunately my first project, called hmhj, is closed source due to concerns from the SNO+ collaboration.

JK

[Jared Kofron]

Yes, my first project was initially also done over ports - the async model was perfect.

[Pablo Platt]

What I'm asking is how you actually send data over the wire.
How does eprologix_cmdr:send_query/3 works?

https://github.com/kofron/dripline/blob/master/src/hp8340b.erl#L100

Thanks

[pietje]

Hi All,

Just my 2 cents.

I am an ex physicist too. Used to do research on QCD (Drell-Yan process) calculating Feynman diagrams.

For a couple of years I've been busy writing an erlang program to handle Feynman diagrams algebraically. Lots of fun. 

regards, Pieter Rijken

 

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Jared Kofron]

Very cool... and unusual for Erlang.  Well, I will be at Erlang Factory this year, so maybe some of us physicists (ex and otherwise) can

discuss it over a beer.

Jared K

[Tony Rogvall]

Wow :-)

I like to see that, is it anywhere on git hub? 

Very early in early in my Erlang career I help a math friend to calculate betti numbers 

(simply put, calculate number of holes in an object given a triangulation of a surface description ) 

The oldest file is dated Jun 11 1992 :-)

I have also implemented the AKS (prime number) algorithm in, it beat the C++ code without even

trying to use all the cores (linear speedup)

Just to mention a few of the math related stuff I have been using Erlang for.

I totally agree

Lots of fun!

/Tony

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"