Tuesday, August 31, 2010

Spots in Southern California, Part 3

How do you build a sun spot?  Previously one needed a sun, which is very inconvenient in terms of logistics and safety issues.  It turns out that now you can build one with just an amazing computer code and a large supercomputer, which is much more convenient and it runs out pretty darn effective.  Below are a real and a simulation sunspot.  I'll let you figure out which is which.

In a truly groundbreaking simulation, Matthias Rempel of the National Center for Atmospheric Research here in Boulder has created a realistic simulation of a sunspot that appears to correctly reproduce almost all of a the observed features of real sunspots.
This is the kind of numerical model most of us computational scientists dream about at night.


  1. Wow, I can't tell which one is which! (But I'm not a solar astronomer either.) I'm going to guess the one on the right is real.

    Regardless, it is amazing such modeling can be done with computers these days. Nick, is this code public? Do you have any idea how many CPU hours this takes to run?

  2. Joe,

    The code is not publicly available for the simple reason that it is being maintained at the moment by one person who doesn't have the time or resources to document or provide user support for it. One of the big problems in numerical astrophysics is that neither the NSF or NASA have funding structures for developing and maintaining large public codes. What is needed here - and in many other areas - is a small staff of scientists & computing experts (maybe 1-2 professors/staff scientists, 2-3 postdocs, 1-2 grad students) to maintain, support, and continuously develop this code. Instead you have one scientist trying to do it all - from the science to the coding to the porting to new systems.

  3. As to how many core-hours it takes to run, the simulation shown above took roughly 2 million core-hours on the NSF's Ranger system at the University of Texas. That simulation has since been run for nearly 24 simulated hours, requiring something like 5 million core-hours. This code can use something like 30,000 cores at once.

  4. Nick,

    I could imagine this is an issue. When I was at LANL there was a dedicated person maintaining one of the big codes we were using and Dan told me the whole time to never do something like that since it can end your science career and force you into being a sysadmin since you stop doing science full time.

    It is unfortunate there isn't money to support people who need to spend a few years maintaining a big code to ensure a good public release with also an understanding that this is important and so they aren't penalized for not "doing science" for a few years.

  5. Joe,

    My personal opinion is that big codes (Enzo, Flash, etc.) are like instruments for space missions. Clearly there need to be scientists driving the project, but it makes no sense to have scientists committing time to things that could be done better by engineers. Just as an astrophysicist should not be building the telemetry or guidance systems for spacecraft, he or she should also not be building the I/O or communication components of a major piece of large scientific codes. The computational experts out there can do it faster and better than the scientists, so we should let them do it.

    Additionally, there are some people that actually enjoy that sort of thing, so while you may want to avoid shepherding the development of a major code, someone else might love it.


To add a link to text:
<a href="URL">Text</a>