• Register your stuff with purx!

    2017-11-02 Markus Demleitner
    TOPCAT Screenshot

    If you open the TAP dialog of TOPCAT, what you see is Registry content.

    The VO Registry lets people find astronomical resources (which is jargon for “dataset, service, or stuff“). Currently, most of its users don't even notice they're using the Registry, as when TOPCAT just magically lists what TAP services are available (image above) – but there are also interfaces that let you directly interact with the registry, for instance GAVO's WIRR service or ESAVO's Registry Search.

    Arguably, the usefulness of the Registry scales with its completeness. With sufficient completeness, the domain-specific, structured metadata will also make it interesting for generic discovery of astronomical data; in a quip, looking for UCDs in google will never work quite well – and without that, it's hard to find things with queries like „radio fluxes of early-type stars”.

    Either way: If you have a data set or a service dealing with astronomy, it'd be great if you could register it. To do this, so far you either had to set up a publishing registry, which is nontrivial even if you have a software that natively speaks a protocol called OAI-PMH (DaCHS does, but most other publishing suites don't) or you could use one of two web interfaces to define your resource (notes for a talk on this I gave in 2016).

    Neither of these options is really attractive if you publish only a few resources (so the overhead of running a publishing registry looks excessive) that change now and then (so using a web browser to update the resource records again and again is tedious). Therefore, GAVO has developed purx, the publishing registry proxy. We've officially announced it during the recent Southern Spring Interop in Santiago de Chile (Program), and the lecture notes for that talk are probably a good introduction to what this is about.

    If you're running VO services and have not registered them so far, you probably want to read both these notes and the service documentation. If, on the other hand, you just have a web-published directory of files or a browser-based service, you probably can skip even that. Just grab a sample record (use the one for a simple browser service in both cases) and adapt it to what's fitting for your website. Then put the resulting file online somewhere and paste the URL of that location on purx' enrollment service. In case you're uncertain about some of the terms in the record, perhaps our crib sheet for metadata we ask our data providers for will be helpful.

    There's really no excuse any more for not being in the Registry!

  • GAVO at AG-Tagung 2017, Göttingen

    2017-09-19 Markus Demleitner
    Photo of our booth

    For the 11th time, GAVO has a booth at a meeting of the venerable Astronomische Gesellschaft (AG). This year, we are in Göttingen, again offering advice to users and data providers at our booth (if you're looking for us: We're close to the entrance of Hörsaal 5).

    And again we have a Puzzler, a little problem easily solved if you know your VO tech – and if you don't we'll gladly help you at our booth. We are also giving hints there, one being released at each coffee break on Tuesday and Wednesday (there are little posters with them, too, if you miss one). Of course, if you're not in Göttingen, you're still welcome to try your hand. You won't get to win our great first prize then, the big Crab Nebula towel (it should be easy to spot on the image above).

    If, on the other hand, you are in Göttingen, be sure to drop by our splinter meeting. Yours truly, for instance, will speak about EPN-TAP (remember And the Solar System, too right here? That's what this is about).

    Update 2017-09-20, 17:00 We've just given out the last hint for the puzzler, and so we can publish them all over on the puzzler archive: Hints for the 2017 puzzler. If you're in Göttingen, you still have until tomorrow 16:00 to hand in a solution and perhaps win our nice and fuzzy Crab Nebula towel.

    Update 2017-09-21, 17:00 And the winner is... again not from Marburg, which is beginning to become a running gag, and they've been unlucky for the last three years in a row. Anyway, here's our proposed solution.

    Our prize towel

  • The Earth is Our Telescope

    2017-07-31 Markus Demleitner
    Antares 2007-2012 neutrino coverage

    The coverage of the 2007-2012 Antares neutrinos, with positional uncertainties scaled by three.

    At our Heidelberg data center, we have have already published some neutrino data, for instance the Amanda-II neutrino candiates, the IceCube-40 neutrino candidates, and the 2007-2010 Antares results.

    That latter project has now given us updated data, for the first time including timestamps, available as the Antares service.

    Now, if you look at the coverage (above), you'll notice at least two things: For one, there's no data around the north pole. That's because the instrument sits beyond the waters of the Mediterranean sea, not far from where some of you may now enjoy your vacation. And it is using the Earth as its filter – it's measuring particles as they come ”up” and discards anything that goes “down”. Yes, neutrinos are strange beasts.

    The second somewhat unusual thing is that the positional uncertainties are huge compared to what we're used to from optical catalogs: a degree is not uncommon (we've scaled the error circles by a factor of 3 in the image above, though). And that requires some extra care when working with the data.

    In our table, we have a column origin_est that actually contains circles. Hence, to find images of the “strongest” neutrinos in our obscore table, you could write:

    SELECT * FROM
ivoa.obscore AS o
JOIN (
  SELECT top 10 * FROM antares.data
  ORDER BY n_hits desc
) AS n
ON 1=INTERSECTS(
  s_region,
  origin_est)

    in a query to our TAP service.

    But of course, this only gets really exciting when you can hope that perhaps that neutrino was emitted by some violent event that may have been observed serendipitously by someone else. That query then is (and we're using all the neutrinos now):

    SELECT * FROM
ivoa.obscore AS o
JOIN antares.data as n
ON
   epoch_mjd between t_min-0.01 and t_max+0.01
  AND
    dataproduct_type='image'
  AND
    1=INTERSECTS(origin_est, s_region)

    On our data center, this doesn't yield anything at the moment (it does, though, if you do away with the spatial constraint, which frankly suprised me a bit). But then if you went and ran this query against obscore services of active observatories? And perhaps had your computer try and figure out whether anything unusual is seen on whatever you find?

    We think that would be really nifty, and right after we've published a first version of our little pyVO course (which is a bit on the back burner, but watch this space), we'll probably work that out as a proper pyVO use case.

    And meanwhile: In case you'll be standing on the shores of the Mediterranean this summer, enjoy the view and think of the monster deep down in there waiting for neutrinos to detect – and eventually drop into our data center.

  • DaCHS 1.0 released

    2017-07-11 Markus Demleitner

    Today, I have released DaCHS 1.0 – after long years in the 0.9 range, it was finally time to do so. The jump in the major version number was an opportunity to remove some cruft that had accumulated over the years; this, on the other hand, means that if you're running DaCHS, you should watch the upgrade and see if anything broke later (this might be the perfect time to add regression tests to your RDs).

    The changelog is below, but before that a bold-faced warning:

    Install python-astropy before upgrading

    This is because DaCHS now depends on astropy rather than pyfits and pywcs. The latter is no longer part of Debian stretch, and so we made the jump to astropy (that would have been due during Debian stretch's lifetime anyway) even before 1.0.

    Now, Debian holds back packages with new dependencies, and due to the way DaCHS' modules are distributed, DaCHS will break when some of its packages are held back. The symptom is error messages like "pkg_resources.DistributionNotFound: gavodachs==0.9.8". If you already see those, a apt-get dist-upgrade should get you in business again.

    With this out of the way, here is an annotated log of the major changes:

    • DaCHS' main entry point is now actually called dachs (i.e., call dachs imp q and such in the future). gavo will work as an alias for quite a while to come, though, and it's still used a lot in the documentation (you're welcome to fix this: the docs are maintained on github).
    • Hopefully more useful manpage (of course, also available with man dachs) – have a peek!
    • UWS support is now at version 1.1 (i.e., there's creationDate in jobs, filters in the joblist, and slow polling).
    • Added “declarative” licenses. Please read the Licensing chapter in the tutorial and slap licenses on your data.
    • Now using astropy.wcs instead of pywcs, and astropy.io.fits instead of pyfits. The respective APIs have, unfortunately, changed quite a bit. If you're using them (e.g., in processors), you'll have to change your code; it's unlikely services are impacted at runtime. (see also How do I update my code?).
    • Removed the //epntap#table-2_0mixin. Use
      //epntap2#table-2_0 instead (sorry).
    • Removed sdmCore (use Datalink/SODA instead); the SODA procs in //datalink are also gone, use the ones from //soda instead (sorry, SODA development has been difficult on the IVOA level).
    • Removed imp -u flag and the corresponding updateMode parse option. If you used that or the uploadCore, just mark the DDs involved with updating="True" instead.
    • Massive sanitation of input parameter processing. If you've been using inputTable, inputDD, or have been doing creative things with inputKeys, please check the respective services carefully after upgrading. See also DaCHS' Service Interface in the reference documentation. The most user-visible change in this department is if you've been using repeated parameters to fill array-valued inputs. That's no longer allowed; if you actually must have this kind of thing, you'll need a custom core and must fill the arrays by hand.
    • In DaCHS' SQL interface, tuples now are matched to records and lists to arrays (it was the other way round before). If while importing you manually created tuples to fill to array-like columns, you'll have to make lists from these now.
    • rsc.makeData or rsc.TableForDef no longer automatically make connections when used on database tables. You must give them explicit connection arguments now (with base.getTableConn() as conn:).
    • logo_tiny.png and logo_big.png are now ignored by DaCHS, all logos spit out by it are now based on logo_medium.png, including, if not overridden, the favicon (that you will now get if you have not set it before).
    • Removed (probably largely unused) features editCore, SDM2 support, pkg_resource overrides, simpleView, computedCore.
    • Removed the argparse module shipped with DaCHS. This breaks compatibility with python 2.6 (although you can still run DaCHS with a manually installed argparse.py in 2.6).

    Even though that's quite a mouthful, I expect few people will actually experience breaking services. If you do, by all means let us know on the DaCHS-support mailing list.

    As usual, the general upgrading instructions are available in the operator's guide; if you plan on upgrading to stretch soon, also have a look at hints on postgres upgrades. Stretch comes with postgres 9.6 (jessie: 9.4), and you should migrate sooner or later anyway.

    Users not using Debian's package management can, as usual, grab tarballs from http://soft.g-vo.org/dachs.

  • ADQL tricks at MPIA

    2017-06-29 Markus Demleitner
    Aerial image of Heidelberg and Königstuhl

    The 2017-06-29 ADQL talk (red circle) from 30000 ft

    Today I was up on Heidelberg's signature mountain, Königstuhl, at the Max-Planck-Institute for Astronomy for a little talk on what I'd provisionally call “intermediate ADQL” – discussing some aspects of ADQL and some TAP techniques that may not be immediately obvious but still generally and straightforwardly applicable to everyday problems. Since I suspect the lecture notes for that talk may be of interest to some readers of this blog, I thought I should share them here.

    What this also contains is a very quick piece of pyVO-based python (which needs both this helper and a recent pyVO) for a use case that comes up fairly often: “Give me all proper motions (radio fluxes, distances, radial velocities, whatever) for object in this region.”

    This uses a discovery case I've been after for quite a while now: Find services by the UCDs of tables within them. And while that's been possible for quite a while on GAVO's Registry UI WIRR, there's still too many services that don't declare their tables to the Registry, and when talking about TAP, the situation is still a bit worse (as has been mentioned in my account of the last interop). So – enjoy the code, but very frankly, you'll still see wires sticking out for a several months yet.

    And if you run a TAP service yourself, please have a look at how to enable table discovery over on the IVOA wiki so we can finally get those pesky wires out of our users' eyes.

« Page 18 / 21 »