After donating lots of his time to create Java programs to reduce some of our data, PhD student Reece Arnott has had to get back to concentrating on his PhD, so can’t help us any more for now. Thanks again to Reece for his contributions! But that leaves us without anyone to carry on Reece’s work, so we need a volunteer who knows Java.
The programs already written take raw output from our detectors, such as our photomultiplier tubes, filter out the noise, detect the real peaks and measure their height, width, area, etc. We need to modify Reece’s program for some of our other instruments. All the resulting programs, after neatening-up, will be available on line as open source applications available to other researchers.
If you have Java skills and some time to help out as a volunteer please contact me—and thanks!
OK, any modifications to the below, or shall I post as is:
We need people with java skills! In particular, we need help improving a java program to reduce some of the data of a fusion research experiment. We need this help because the PhD student who was doing this for us has gone back to concentrating on his PhD, so he can’t help anymore (Thanks again to Reece for his contributions!). The program is already written to:
* take raw output from our detectors, such as our photomultiplier tubes;
* filter out the noise;
* detect the real peaks and measure their height, width, area, etc.
We need to modify Reece’s program for some of our other instruments. All the resulting programs, after neatening-up will be available online as open source applications available to other researchers to speed up the advancement of fusion.
Here’s some info about us and what we’re doing:
The Focus Fusion Society (FFS) is a 501(c)(3) tax-exempt membership organization located in South Bound Brook, New Jersey.
Our mission is to bring people together to pursue the dream of safe, clean, affordable, abundant energy from aneutronic fusion, to ensure that the ensuing technology is made available to everyone, and to foster a pro-research ethic and pro-fusion culture.
Virtual volunteering, as it has been done to date,* is exactly like in-person volunteering, but the work takes place remotely. It’s like telecommuting to work.
So, all of the same management rules are in place. You will usually be trained, vetted, and accepted for a volunteer position. You will have a direct manager. You will do work and will send it to your manager for review. The manager will approve the work or ask for revisions. The manager will tell you that you’ve done an amazing job – or that you could stand a little more training. Communication will happen via email, typically. But it could also happen via a phone call – or via a project management web site like Basecamp. This is volunteering, remotely, from a more convenient location.
If you review my definition of microvolunteering, you can see that virtual volunteering checks off only one of the four key defining characteristics: convenience. Just to review those points briefly, microvolunteering is: convenient, bite-sized, crowdsourced, and network-managed.
Virtual volunteering is convenient, small or large sized, and managed via a traditional one-to-one or one-to-many hierarchical management method.
Why are these distinctions so important? Because they lead to a process of work that is wildly different. And yet, the result of the work may be precisely the same! How’s that for interesting?
Does this apply here? I’m thinking ABD Reece has cleared away some of the thornier obstacles, and it may now be down to a “bite size” thing for those Java scripters who are over the learning curve.
Developing this data processing application wouldn’t be a “micro volunteering” task, but more of a “virtual volunteering” as Rezwan would put it. It’s a classical “open source” development.
There are several levels of open-source developers:
* bug reporter / tester
* code contributor
* code maintainer
A code maintainer is a long-time volunteer who has deep understanding of the code. We need at least one maintainer who coordinates patches and coaches new code contributors. Most likely it’s just one person anyway, but he/she needs to understand the code globally.
The problem is, that the user base is very narrowed. Only the LPP Lab uses it. So they are the only ones that qualify for “bug reporter”, because they have the data and can assess the results. Other open source programs like Firefox need multiple layers of volunteers, but LPP would need someone more focused, at least one person.
As for the skill-set of the developer, LPP most likely not only needs a Java programmer, but maybe someone with a statistics or mathematical background. We’ll see, when the code is published.
Just my experience with developing the DPF filament simulation for LPP: As I am a “Java Enterprise Developer”, I’m mainly used to do data processing based on strings. Haven’t done any real calculation or mathematical algorithms in my professional career at all. That’s how I underestimated the task on developing the DPF filament simulation. I’ve done a particle-in-cell simulation for my master’s thesis, but LPP needed a fluid simulation. Luckily the programming of the simulation was mainly done by Jeff Schoen (in Java), and is now done by Warwick Dumas (in C++), physics by John Guillory. I was able to coach Warwick, but only because I’ve worked with Jeff’s solution before. Warwick’s doing all the magic now.
I reckon there about 10% percent computer programmers lurking here and half of them do Java. But it’s not like “I do some Java, I can do it for five minutes”. Maybe the task at hand is easier, just some image manipulation. Stuff you’ve learned in your computer science classes. So go ahead and do it, if you’re willing to put in more than five minutes.
I’d love to help, but I think I’m in the same boat as Reece. My PhD is at the stage where I really need to be concentrating on that. Also I’ve volunteered before for other things and never delivered so I don’t want to let you down again, Eric.
However, having said that when the time comes I’m eager to make a contribution. My fluid plasma code is written in C with final analysis/plotting done mostly in matlab, but I have used java before.
Henning is correct in that the language skill is less important than the maths/stats regarding the numerical methods to extract information from the data, carrying through errors to give robust figures suitable for scientific interpretation and publication.
It is basically a system whereby the data from each shot is fed automatically from all the diagnostics into a central SQL database. The raw datasets can be accessed via a simple set of APIs for C,Java,Matlab etc. Any analysis code then can, by including the relevant header, extract raw data for any shot, returning the analysed data to the database.
Other higher level codes can then take the processed data from many diagnostics and combine them to perform more complex analysis. The final stage being comparing analysed data from many shots to uncover trends, scaling etc.
I’m a Java developer with A level (UK college level) maths and science qualifications ; my maths ability is reasonable (sounds like most of what’s required is very basic calculus skills, but that’s just my unqualified guess )
It does sound like most of the maths is done, actually, and all that’s really required is adjusting things for scale, and probably writing some routines to consume different data formats (something I do a lot).
I have experience of working on open-source projects also.
Drop me a mail (possibly with the source code) and we can communicate.
there is a conventional wisdom that breaks tasks down into that which can be done in a single day only, (as estimated by the developer who will do it); the proposed task list is prioritized by the product owner, and grouped into a list items that will consume no more than 2 weeks total. after the two weeks, the cycle repeats, with a new list.
[Bernie M.] Is it possible for you to post the code somewhere for others to look at? Assuming it is going to be open source software, you could post it someplace like github.com and people could check it out, work on parts of it, and check it back in. Do you know how to do any of that?
To which I said, “We’re thinking this may not be something for Sparked as it will involve more stats and math, and not just java.” And
[Archimedes T.] I think you both have the right idea. Although math and stats would help a lot especially in the “business” aspect. Sharing the existing codebase and improving it would help in the “delivery” aspect.
By sharing the codebase and hopefully improving on it, you can provide a place where people who know the stats and math can have their ideas implemented more easily.
It is the same with any properly run application development shop, the “business” part is translated into the code. However, if the code base is not the best it can be, it would make things more difficult to note just implement, but to test and perform performance analysis.