PDA

View Full Version : SDSS: some interesting, um, facts



Nereid
2010-Oct-14, 02:46 PM
I'm reading Ann Finkbeiner's "A Grand and Bold Thing" (Free Press, 2010), about SDSS (Sloan Digital Sky Survey) - a book well-worth reading, IMHO.

Here's a passage that had me in stitches; it's about the Sky Mapper, a devise which maps the locations of fibres on the specially drilled plates to the locations of their ends at the entrance to the spectrograps: "He explained further that they wanted to scan each plate twice, to protect against "the famous APO [Apache Peak Observatory] moths, which are optically thick"". Do I have a, um, strange sense of humour? Or did I not provide enough context?

And then there's this bit about how the website came to be what it is:

Jim Gray advised Alex that best show[-and-tell] would not be to type a query into a database and get back a row of numbers, but instead to make a pretty website. Alex did a first design of the website and showed it to his thirteen-year-old son, Tamas, who said that no decent your person would consider it and that Alex should try for something that looked like a gaming interface. Alex and Gray thought that if the Sloan didn't want their SQL archive, maybe kids - and by extension teachers and school systems - would. So Alex and Gray put together a prototype of what became the Sky-Server, Sloan's public presence in the world.

Nereid
2010-Oct-14, 02:49 PM
Oh, and then there's this, about Galaxy Zoo:

"A zooite got home from work one night, fired up Galaxy Zoo, and let his five-year-old watch him classify galaxies. The five-year-old asked if he could play the galaxy game again tomorrow. The zooite said of course but it wasn't a game, it was science, and the five-year-old said, stunned, "We're doing SCIENCE?""

StupendousMan
2010-Oct-14, 04:41 PM
"He explained further that they wanted to scan each plate twice, to protect against "the famous APO [Apache Peak Observatory] moths, which are optically thick"".




Yup. During moth season (the fall, as I recall), the little critters fly and creep
and burrow into small, warm places -- like the innards of motors and cameras.

ngc3314
2010-Oct-14, 05:50 PM
Ah, yes, moths. Some are quite large and get into places that you'd think hermetically sealed. Witness this image of the filter wheel from the prime-focus CCD camera at the Kitt Peak 4m telescope:

http://www.astr.ua.edu/gifimages/moth.gif

This confirmed my impression that flat-field corrections do a good job on the effects of dead insects, but not live ones. It apparently lasted until the first filter rotation (and we found this only the next day pulling the instrument off).

Rumor has it that flying insects, mostly moths, rendered the original laser-alignment system on the MMT ineffective - they interrupted the beams and sent the actuators off toward a limit switch. Or so it has been said, anyway.

Nowhere Man
2010-Oct-14, 11:22 PM
Still a few bugs in the system, I see.

Fred

George
2010-Oct-15, 04:25 AM
I'm reading Ann Finkbeiner's "A Grand and Bold Thing" (Free Press, 2010), about SDSS (Sloan Digital Sky Survey) - a book well-worth reading, IMHO.

Here's a passage that had me in stitches; it's about the Sky Mapper, a devise which maps the locations of fibres on the specially drilled plates to the locations of their ends at the entrance to the spectrograps: "He explained further that they wanted to scan each plate twice, to protect against "the famous APO [Apache Peak Observatory] moths, which are optically thick"". Do I have a, um, strange sense of humour? Or did I not provide enough context? I doubt you need say more, I laughed when I read it, though this was when I read her book. [I gave her a positive review in Amazon, after sending her a list of a very few number of trivial errors. :) I am sure she would appreciate hearing from you.]

It is a great trials and tribulation story, and with a great ending.

George
2010-Oct-15, 04:53 AM
Ah, yes, moths. Some are quite large and get into places that you'd think hermetically sealed. Witness this image of the filter wheel from the prime-focus CCD camera at the Kitt Peak 4m telescope: Do they prefer quasars over candles? :)

Was this related to the Mayall telescope study on dark matter and gravity lensing, which you wrote about in "The Sky at Einstein's Feet"?

ngc3314
2010-Oct-15, 12:30 PM
Was this related to the Mayall telescope study on dark matter and gravity lensing, which you wrote about in "The Sky at Einstein's Feet"?

Slightly more pedestrian - large-scale structure at z=2.4. (Traced one structure, found none in additional fields).

mahesh
2010-Oct-15, 01:33 PM
HarHar!! Funny Nereid. What a lovely phrase...optically thick...


Yup. During moth season (the fall, as I recall), the little critters fly and creep
and burrow into small, warm places -- like the innards of motors and cameras.

This reminds of a lovely and curious incident, as it happened to our Venerable Mr RickJ...
http://www.bautforum.com/showthread.php/91262-Note-to-Paramount-users?highlight=squirrels%3B+nuts

We won't be travelling alone in space. How very comforting!

parejkoj
2010-Oct-15, 06:13 PM
Yup, there are quite a few funny bits in that book, besides the *HUGE DRAMA* involved in getting a project like this going. Definitely a recommended read.

It's particularly strange to me to read about people that I know, and the drama they were involved in ~10-15 years ago.

StupendousMan
2010-Oct-15, 07:24 PM
It's particularly strange to me to read about people that I know, and the drama they were involved in ~10-15 years ago.

You and I think alike -- I've not read the book yet because I suspect that it will be strange and perhaps a bit disturbing to read about all that drama ....when I was part of it. Yipes.

Nereid
2010-Oct-15, 08:18 PM
The one thing that most distressed me was the apparent disregard of out-of-the-textbook project/program management. Of course I wasn't there, as in privvy to leadership discussions/decisions, but so much of the delay and cost overruns could surely have been at least alleviated, even avoided, if the many decades of project/program management experience - available even in textbooks - had been deployed.

Goodness, the book even recounts the tribulations of one such manager, who did exactly what he was hired to do, only to have his work filed away and never read, much less implemented!

Another thing: although it isn't entirely clear, it seems that some of the best and brightest undergrads/post-docs had their scientific careers adversely affected by working on non-science parts of SDSS; they made great, even essential, contributions to the success of the endeavour, but may not have been rewarded in any way meaningful to their aspirations and careers as astronomers. If true, it's very sad indeed.

Nereid
2010-Oct-15, 08:32 PM
Does anyone know if the author, Ann Finkbeiner, is related to Doug Finkbeiner, who was most definitely involved in the project (he's now a Princeton, according to ADS)?

re the APO moths: there's a delightful couple of pages describing the development of 'a moth ejector system'; here's the result:

Further research found that, as French said, "interrupted air blasts they do not like." Eventually he built a moth ejector system that blew air intermittently through pipes with holes along their sides. "A 2 hertz puffer system is what we found to be most effective." He mounted the system on the most sensitive parts of the telescope, and though the moth problem didn't completely resolve, it was much improved.

parejkoj
2010-Oct-15, 08:40 PM
You and I think alike -- I've not read the book yet because I suspect that it will be strange and perhaps a bit disturbing to read about all that drama ....when I was part of it. Yipes.

StupendousMan: Haven't one or the other of us mentioned that we think alike before? But the book really is very good, and unless memories of that time are too hard for you to deal with (which I could certainly understand), I really do recommend it.

Nereid: Keep reading. There's (some) light at the end of the tunnel. (One of those people who contributed a lot to infrastructure is now my boss, and the others have done alright too...)

Astronomers aren't very fond of "management," figuring that we're smart enough to sort things out ourselves. SDSS was not the first astronomy project to have problems when this view met reality, but it was one of the larger such collaborations and I think one of the first to actually bring in outside help with this problem.

For those reading this thread who aren't as familiar with the SDSS, the book is a good read even if you don't know the *agonists, both pro- and ant- (who are often the same person on different days). My other half has been enjoying it, without such a background.

Nereid
2010-Oct-15, 09:19 PM
[...]

Nereid: Keep reading. There's (some) light at the end of the tunnel. (One of those people who contributed a lot to infrastructure is now my boss, and the others have done alright too..
I've finished the book, and did note that at least some of those folk did well to very well; however, I haven't checked in detail to see if that is/was true of all those mentioned (and, even more important, those who gave years of their lives to the project and were not mentioned).


Astronomers aren't very fond of "management," figuring that we're smart enough to sort things out ourselves. SDSS was not the first astronomy project to have problems when this view met reality, but it was one of the larger such collaborations and I think one of the first to actually bring in outside help with this problem.

[...]
It's a crying shame, a shameful waste of resources, etc, etc, etc.

And it matters so much more now, with projects involving many institutions, far larger budgets, and so on.

In the beginning of the book Gunn is quoted on his view that astronomers had the ultimate responsibility for the flawed Hubble mirror; the same must also be true for delays and (very considerable!) cost overruns in projects like SDSS ... and if, one day, a very good project gets killed because, in essence, the astronomers didn't make use of (or rely upon) well-tested, proven techniques in project/program management, well, shame on them.

In a way it's an attitude that is hard to comprehend. I mean, almost all astronomers respect their fellow scientists in other fields, and would rarely think to completely disregard many-decades of experience in another field. And it's not like project/program management is a black art, like software writing (though that too has seen tremendous progress in the last few decades, to the point where much of software engineering is true to its name).

OK, I'll get off my soapbox now ...

StupendousMan
2010-Oct-15, 10:28 PM
I mean, almost all astronomers respect their fellow scientists in other fields, and would rarely think to completely disregard many-decades of experience in another field.

I think you are giving too much credit to "almost all astronomers" in your statement. I have observed that some of the people with whom I've worked in astronomy believe that astronomers (and physicists) are just better at almost anything than anyone else. You might read a bit of Feynman's book Surely You're Joking, Mr. Feynman!, in the chapter about his adventure in biology.

In defense of the SDSS, remember that before the project was started, _most_ of the work done by the leaders of the effort was done in very small teams -- 1 to 5 people, perhaps. Things had always worked out well with such small teams, so one might understand why it was surprising to so many people when they discovered that it was different when one was part of a BIG team. It was just a completely new regime.

parejkoj
2010-Oct-16, 12:11 AM
Stupendous Man: *YES!*

There's something I like to call the "physicist's conceit" (which generally applies to astronomers and engineers too): "Because I have a physics Ph.D., I'm a really smart person, and so I can easily understand any other field and don't need to listen to experts in that field." There are plenty of examples of this, such as Hal Lewis's recent comments on climate science. Hell, I have to watch for it in myself sometimes.

Nereid: your comments about the "unmentioned" workers are appropriate. I don't know all the details, but it is something that I've heard many of the SDSS higher-ups mention when talking about job prospects for their or other students. There's certainly some "looking out for our own" among those who contributed to SDSS, where it is understood that infrastructure is important. Whether this finally gets translated to better job prospects, I don't have any actual numbers, though.

One comment from my other half (who also just finished the book): "Since I understand how the science is actually done by you, it certainly isn't quite as glamorous and exciting as she makes it seem in the book. All of those interesting discoveries came about from a lot of computer programming and staring at data and plots." Which is absolutely true... :(

loglo
2010-Oct-16, 10:10 AM
XKCD - "physicists" - " Liberal arts majors may be annoying sometimes but there's nothing more obnoxious than a physicist first encountering a new subject." (http://xkcd.com/793/) :)
(make sure you read the flyover text)

George
2010-Oct-17, 01:41 AM
Does anyone know if the author, Ann Finkbeiner, is related to Doug Finkbeiner, who was most definitely involved in the project (he's now a Princeton, according to ADS)? They are not related, surprisingly. I was curious why she made no mention one way or another since I know no other Finkbeiners, so I asked her. :)


re the APO moths: there's a delightful couple of pages describing the development of 'a moth ejector system'; here's the result:
The variable frequencies tried made it that much more amusing and true-to-life. :)

ngc3314
2010-Oct-17, 04:50 AM
In a 2008 "debate" on the cultures of particle physics and astronomy, Simon White was asked what astronomers could learn from physicists. "Hire project managers".

In a sense, SDSS was on the cusp among ground-based projects between the traditional way of having astronomers in charge and hiding construction costs and time overruns in academic budgets, and the later realization that systematic project management was crucial once there were elements in which time really did translate to cost (i.e. construction being outsourced beyond academia, external funding with deadlines...) Keck (IIRC) waited until the IRAS project manager was available; this realization had come in a couple of decades earlier for space projects, where cost and spread of effort were so large to begin with. I know of one satellite program which was cancelled for poor project management while on track to be approved for final flight-hardware construction.

The sheer scope of SDSS, in complexity, number of institutions/individuals involved, as well as cost, was something astronomers had trouble coming to grips with. Besides, Jim Gunn was at the center of it all. His reputation continues to be such that having him expressing interest in designing something (say, a 4000-object fiber-fed triple spectrograph) is believed to retire its technical risk. This complexity did finally dawn on the partners - Jeff Pier has said that the most important thing he accomplished during a brief stint as head of the SDSS consortium was convincing the partners that they needed to hire genuine professional project management.

Interestingly, in Gunn's open letter about the HST mirror fiasco, he cites the distance of astronomers organizationally from the engineering as a contributing factor in the foulup. It is widely believed that the likelihood of project success is increased by having knowledgeable astronomers close to the management, but I can't demonstrate that with what I've dug up on space astronomy projects (though I continue to try to collect data). During the rampup to what became Gemini, some of the astronomical management at NOAO was formally studying project management.

(HST project management is a very twisty path in its own right. Robert Smith has pretty much laid the whole story out - good, bad, and ugly. Having multiple equal places at the top level of the organizational chart is a bad thing).

StupendousMan
2010-Oct-18, 01:21 AM
One of the real mistakes made at the start of the SDSS was to confuse "manpower" with "headcount". It was clear at the start of the project that there was a great deal of work to do -- some in the design and construction of instruments and telescopes, some in the design of calibration techniques and data reduction, some in the analysis of the results. "We will need N people working full-time for M years to do these tasks", some report might read. There were quite a few institutions in the consortium, and some people simply counted the faculty and post-docs at the member institutions. "Great, there are a total of N people if you add them all up."

Of course, very few of those people had any expertise or willingness to build hardware, do calibration, or write software. Most of them DID have expertise and willingness to analyze the data after everything was working ... but that wouldn't help the project to begin. This was one of the reasons things went well past schedule at the beginning.

Another big reason was the magnitude of the error people made in underestimating the effort required for the second item in that list: calibration and, especially, data reduction. We learned the hard way that writing software is a skill which is required for any large survey project to succeed, but one that is given very little weight in the hiring process. After all, writing software isn't science.

:-(

ngc3314
2010-Oct-18, 12:38 PM
Another big reason was the magnitude of the error people made in underestimating the effort required for the second item in that list: calibration and, especially, data reduction. We learned the hard way that writing software is a skill which is required for any large survey project to succeed, but one that is given very little weight in the hiring process. After all, writing software isn't science.

And that gets to another factor where the high-energy physicists grappled first - in a huge project in which skills of building hardware and writing software are key, best done by scientists who have gone down very particular career paths, and universities are the major employers, how do you (as a community) manage to reward those by considering them equivalent to pure research output for purposes of hiring and promotion? In this case, a good bit of deliberate finesse is needed, because the field isn't completely in charge of the criteria within academia. "Reward" in this case is even more than simple fairness - it's looking to the future health of the discipline.

Nereid
2010-Oct-18, 07:22 PM
There are a few ironies here, though perhaps more perceived than real.

First, although astronomers are not physicists, I don't think they're generally as, um, arrogant as physicists.

Second, I should hope that lots of the history of the last few decades has produced some greater humility, or at least acceptance that being a good physicist does not mean you are a master of the universe.

Third, according to the book, Fermilab got involved in SDSS at the tail end of the SSC cancellation, so you'd think that at least those who were involved in the SSC had learned a thing or two about project and program management!

But no, it seems not, or perhaps just that the Fermilab people assigned hadn't had hands-on experience (and disappointment), or weren't given enough authority.

(BTW, a rule of thumb on the difference between project and program management: the former fits within a very clear, single agency structure; a project manager 'only' needs to develop WBS from agreed, unambiguous, measurable goals and implement it; a program manager has a bunch of projects to manage, often within a multi-agency structure, often with vague goals, uncertain budgets, etc)

Then there's the engineers' maxim, mentioned in the book: faster, cheaper, better; pick two. A failure to do so often produces a project that meets only one (at best).

Another irony: astronomers have used project managers, and management, frequently over the decades: contracting out for the construction of (new) major telescope infrastructure for example ... the dome, power supply etc (including back-up), lodge (on the remote mountain top), access roads, etc. The failure to appreciate the benefits of applying the same disciplines and skills to the beloved instrumentation and higher-level infrastructure is, um, rather schizophrenic don't you think?

One aspect that was, and to some extent still is, not well nailed down: software. Although many of those who ended up doing a lot of SDSS coding etc were not trained software engineers, it's pretty clear (from the book) that SDSS' experience is not much different from any large IT project of the time ... developing good code etc was (and still is, to some extent) a black art, and coders vary enormously in efficiency and effectiveness, even when the goal is clear. Further, there was (and still is, to some extent) no reliable guide as to whether a person can, or will, write good code quickly - not their math skills, not their language skills, not the number of published papers, ...

ngc3314
2010-Oct-19, 02:01 PM
Robert Lupton (as close to an indispensable programmer as SDSS had) has an interesting summary (http://www.astro.princeton.edu/~rhl/Talks/SDSS-lessons.pdf) of software lessons learned. His bullet-point lines are as follows:

You need a strong and impartial project manager.

Donít go into a project that isnít fully funded.

Neither Science nor Software can be run as a democracy.

When, What, and How to Review.

Standard software practices are necessary.

Distribute Data and Information Freely

Avoid single points of failure.

Find some way to reward people working on the project.

Strive to ensure that the software takes full advantage of the hardware, even at the beginning of a project.

Donít generate an inverted management structure.

(His brief explanations of each point are also enlightening).

Strange
2010-Oct-19, 02:08 PM
Goodness, the book even recounts the tribulations of one such manager, who did exactly what he was hired to do, only to have his work filed away and never read, much less implemented!

Probably a victim of the usual "we haven't got time to do all that project management stuff - we have a complex project to do and not much time..."

Nereid
2010-Oct-19, 02:45 PM
Robert Lupton (as close to an indispensable programmer as SDSS had) has an interesting summary (http://www.astro.princeton.edu/~rhl/Talks/SDSS-lessons.pdf) of software lessons learned. His bullet-point lines are as follows:

You need a strong and impartial project manager.

Donít go into a project that isnít fully funded.

Neither Science nor Software can be run as a democracy.

When, What, and How to Review.

Standard software practices are necessary.

Distribute Data and Information Freely

Avoid single points of failure.

Find some way to reward people working on the project.

Strive to ensure that the software takes full advantage of the hardware, even at the beginning of a project.

Donít generate an inverted management structure.

(His brief explanations of each point are also enlightening).
Interesting.

A lot of these are Project Management 101, or easily derivable from that source.

It's really interesting that Lupton - a star-coder, productive SDSS person extraordinare (according to the book we've built our discussion around) - includes "Standard software practices are necessary" in his list! Has software development been tamed, and is now 'just' another branch of engineering?

Van Rijn
2010-Oct-20, 05:27 AM
It's really interesting that Lupton - a star-coder, productive SDSS person extraordinare (according to the book we've built our discussion around) - includes "Standard software practices are necessary" in his list! Has software development been tamed, and is now 'just' another branch of engineering?

Pretty much, but let's put it this way: Not following standard software practices on a large project is a programming nightmare. Say, for instance, nobody bothered to think through the requirements and they just have somebody plunge in and start coding, or they come up with a poor database design, or they pick a programming language that almost nobody uses, or they don't document their code, or the code is so opaque it looks like it's from an obfuscated C contest, or nobody on the project knows how to properly test (or worse, assume it isn't necessary) or . . .

Er, well, you get the idea.

Van Rijn
2010-Oct-20, 05:50 AM
One aspect that was, and to some extent still is, not well nailed down: software. Although many of those who ended up doing a lot of SDSS coding etc were not trained software engineers, it's pretty clear (from the book) that SDSS' experience is not much different from any large IT project of the time ... developing good code etc was (and still is, to some extent) a black art, and coders vary enormously in efficiency and effectiveness, even when the goal is clear.


I haven't read the book, but if somebody makes coding look like a black art, they're probably doing something wrong.



Further, there was (and still is, to some extent) no reliable guide as to whether a person can, or will, write good code quickly - not their math skills, not their language skills, not the number of published papers, ...

There is one reliable guide: Testing their programming skills.

Strange
2010-Oct-20, 09:07 AM
Then there's the engineers' maxim, mentioned in the book: faster, cheaper, better; pick two. A failure to do so often produces a project that meets only one (at best).

I had a particularly frustrating time on a project with this. The product manager used this mantra but when I responded by saying that we needed to identify which parts of the spec can be traded-off in return for time (or quality, cost as appropriate) he refused, saying all parts of the spec must be completely implemented. I later realized that every time he said "we can pick two" he picked a different two; forcing us to meet all three. Guess what: we failed on all three.


One aspect that was, and to some extent still is, not well nailed down: software. Although many of those who ended up doing a lot of SDSS coding etc were not trained software engineers, it's pretty clear (from the book) that SDSS' experience is not much different from any large IT project of the time ...

I suspect most software developers are (still) not trained software engineers. And they are certainly not often supported by good management to enforce good engineering practice. (You should see where I work: I think they use the "slapstick" development process)


developing good code etc was (and still is, to some extent) a black art, and coders vary enormously in efficiency and effectiveness, even when the goal is clear.

I wonder how often the goal is clear; how often is there a good well-written spec that has been validated, at least informally. And that doesn't just change at the whim of management several times through the project (without allowing for the extra time/resource that requires).

ngc3314
2010-Oct-20, 12:30 PM
I wonder how often the goal is clear; how often is there a good well-written spec that has been validated, at least informally. And that doesn't just change at the whim of management several times through the project (without allowing for the extra time/resource that requires).

At the start of SDSS, there was a painful sort-of-counterexample still fresh in astronomers' minds. In the 1980s, tens of millions had been spent for a contractor to develop a ground processing system for Hubble data. The code met spec, but the spec had been miswritten so that the code could not actually process 24 hours' worth of data in 24 hours. A large number of astronomer-programmers were hired in a great hurry to redo the whole thing. That approach worked in that case, but one could argue that it left just the wrong precedent for yet more complex software efforts.

Strange
2010-Oct-20, 02:08 PM
One of the best ways I have found to validate a spec (after a thorough review by interested parties) is to start writing the test plan. This forces the test developers to start thinking through exactly what the spec does and, more importantly, does not say.

StupendousMan
2010-Oct-20, 05:12 PM
Has software development been tamed, and is now 'just' another branch of engineering?


Software development is a lot more difficult when you have 4 teams of people at 4 different institutions, and no one at institution A has any authority over anyone at institution B ....

ngc3314
2010-Oct-20, 07:20 PM
Software development is a lot more difficult when you have 4 teams of people at 4 different institutions, and no one at institution A has any authority over anyone at institution B ....

... so when you're ready for a relaxing vacation, come on down and herd these cats with me.

Jerry
2010-Oct-29, 03:44 PM
"Strive to ensure that the software takes full advantage of the hardware, even at the beginning of a project."

This is downright dangerous; as dangerous as taking full advantage of a 20-year-old - you don't know what the hardware will mature into.

I would go with "take advantage of the last generation of mature hardware"...and do everything you can to minimize memory swapping.

Cougars, not wildcats;)

ngc3314
2010-Oct-29, 04:29 PM
"Strive to ensure that the software takes full advantage of the hardware, even at the beginning of a project."

This is downright dangerous; as dangerous as taking full advantage of a 20-year-old - you don't know what the hardware will mature into.

I would go with "take advantage of the last generation of mature hardware"...and do everything you can to minimize memory swapping.

Cougars, not wildcats;)

I took "hardware" to mean telescope, spectrograph, and giant one-of-a-kind array camera, which don't charge nearly as much during a project as the available computing hardware. (But indeed, in general, memory swapping = ungood, maybe even doubleplus ungood. I've had machines where you can hear the paging, and you know and wince when it starts to bog down). I have had experience with some of the reasons trying to couple too tightly to the Latest and Greatest computing hardware can be a terrible idea in distributed projects.

Grey
2010-Oct-29, 05:00 PM
Oh, and then there's this, about Galaxy Zoo:

"A zooite got home from work one night, fired up Galaxy Zoo, and let his five-year-old watch him classify galaxies. The five-year-old asked if he could play the galaxy game again tomorrow. The zooite said of course but it wasn't a game, it was science, and the five-year-old said, stunned, "We're doing SCIENCE?""Hmm. I hadn't thought about this. This might be something my six-year-old son would have fun doing together. I think I'll have to try it out this weekend. :)

ngc3314
2010-Oct-29, 06:32 PM
Hmm. I hadn't thought about this. This might be something my six-year-old son would have fun doing together. I think I'll have to try it out this weekend. :)

"This is the Zoo your'e looking for. You do have to see these galaxies. You will never again go about your business."

Grey
2010-Nov-01, 03:50 PM
Yes, classifying galaxies was definitely a hit with my young son. Thanks for the suggestion!