<!DOCTYPE html>
<html data-lt-installed="true">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body style="padding-bottom: 1px;">
<p>Hi again,</p>
<p>For completeness about the <b>IRFs</b>, here are the talk made
by Karl Kosack during the HEIG online meeting in Oct 2023 : <a
moz-do-not-send="true"
href="https://wiki.ivoa.net/internal/IVOA/HEIG_23Oct18/ctao_irfs.pdf"
class="moz-txt-link-freetext">https://wiki.ivoa.net/internal/IVOA/HEIG_23Oct18/ctao_irfs.pdf</a>,
and by me during the Interop meeting in Malta : <a
moz-do-not-send="true"
href="https://wiki.ivoa.net/internal/IVOA/InterOpNov2024DM/BKhelifi_VHEDM_v2_compressed.pdf"
class="moz-txt-link-freetext">https://wiki.ivoa.net/internal/IVOA/InterOpNov2024DM/BKhelifi_VHEDM_v2_compressed.pdf</a>.</p>
<p>As reminder for the VHE-IACT:<br>
- same pipeline is processing observational raw data and simulated
raw data: from photo-electrons integrated within a hardware
temporal window to reconstructed event list (RA, DEC, energy, and
time)<br>
- aeff, psf and edisp are gamma-ray responses: simulations are
used to produce them<br>
- background rate: because the simulations of cosmic rays are not
precise enough, we are using real data (real event list) from
regions with no gamma-rays source to produce this IRFs<br>
- the IRFs are adjusted to the same observational and instrumental
conditions of each observation : this adjustment means heavy
processing of interpolations using quantities measured during an
observation. The interpolations are made with different parameters
that are also stored into the event list, like: elevation,
azimuth, atmosphere profile - summer/winter, atmosphere
transparency (lidar or cosmic-ray scaled rate), telescope status -
number and hardware configuration, Night Sky Background measured
by the camera, measured number of "broken pixels".<br>
Conclusion: IRFs are like events - heavy processing with the same
observational and instrumental parameters. They are NOT raw data
(for us, raw data = photoelectron number from each pixel of each
camera of each telescope). IRFs and event list are frequently
called "science-ready data" by us (see
<a class="moz-txt-link-freetext" href="https://vodf.readthedocs.io/en/latest/specification/level-1/index.html">https://vodf.readthedocs.io/en/latest/specification/level-1/index.html</a>). <br>
<br>
</p>
<p>About the current definition of <b>calibration level</b> in
ObsCore:<br>
- the data product type <i>image</i> can be calib_level 2 and 3
(recalibrating from IRAS images) => the calibration level is
experiment-dependant!<br>
- the data product type <i>spectrum</i> is a calib_level 1 ->
ObsCore then stores well "raw data"!<br>
- a <i>sed</i> is 3 and <i>timeseries</i> is 4, but a <i>timeseries</i>
with 1 bin (in time) IS strictly identical to a <i>sed</i> with 1
bin (in energy) -> they should have the same calibration level
in reality<br>
- <i>spectrum</i> is 1 and <i>event</i> is 1 => same
calibration level for an astrophysical quantity and an
instrumental quantity (no coherence)</p>
<p>==> I think that it would be a real challenge to make a
coherent data model that is experiment independent of this
calib_level definition!<br>
</p>
<p>Given this apparent randomness and the arguments given in the
first paragraph of my email, we will use the same calib_level for
events and responses, which will be (based on the table 2 of
ObsCore) equal to 1 if using the event calib_level of table 2, OR
equal to 2 if using the definition made in the text ("Level 2:
Calibrated, science ready data with the instrument signature
removed."), OR equal to 3 is using the definition made in the text
("Level 3: Enhanced data products like mosaics, resampled or
drizzled images, or heavily processed survey fields. Level 3 data
products may <u>represent the combination of data from multiple
primary observations</u>."). We are then proposing "2" in this
context (the average between 1, 2 and 3)</p>
<p>.<br>
As you can see, we try to do our best despite the historical
incoherence of current definitions. The other funny example is
that the UCD associated to electron is not linked to a
'phys.particle'.<br>
I think that our work, as illustrated in the DM work made by
Mathieu during the Interop in Bologna in 2023 -- already 3 years
ago -- (<a moz-do-not-send="true"
href="https://wiki.ivoa.net/internal/IVOA/IntropMay3023DM/2023-05-11_IVOA_meeting_-_VOHE.pdf"
class="moz-txt-link-freetext">https://wiki.ivoa.net/internal/IVOA/IntropMay3023DM/2023-05-11_IVOA_meeting_-_VOHE.pdf</a>),
is full of coherence for the inclusion of HE+ data into IVOA.</p>
<p>Cheers,<br>
Bruno</p>
<p><br>
</p>
<div class="moz-cite-prefix">Le 20/03/2026 à 09:42, Bruno KHELIFI
via heig a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:191863059.14986274.1773996162234.JavaMail.zimbra@apc.in2p3.fr">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; direction: null; color: #000000;"
data-attr="forced_root_block_attrs">
<div>Hi all,</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"> </div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">This is a pleasure to see
active thoughts from anyone to expose the new HE products!</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"> </div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">Few words inline..</div>
<div> </div>
<div id="signature-content-da635f11-d113-45d6-a470-925f0c958d7f"
data-marker="__SIG_PRE__">
<div>
<div><br>
---------------------------------------------------<br>
Bruno Khelifi<br>
Physicist in CNRS, APC, Paris<br>
Phone: +33.1.57.27.61.58 - Fax: +33.1.57.27.60.71<br>
APC, Universite Paris Diderot-Paris 7<br>
Bat. Condorcet, Case 7020, 75205 Paris Cedex 13</div>
</div>
</div>
<div> </div>
<div>
<div id="OLK_SRC_BODY_SECTION">
<div id="OLK_SRC_BODY_SECTION">
<blockquote
style="margin: 0 0 0 .8em; border-left: 1px #ccc solid; padding-left: 1em;">
<hr id="MESSAGE_DATA_MARKER"><strong>De: </strong>BONNAREL
<a class="moz-txt-link-rfc2396E" href="mailto:francois.bonnarel@gmail.com"><francois.bonnarel@gmail.com></a><br>
<strong>à: </strong>Ian <a class="moz-txt-link-rfc2396E" href="mailto:ievans@cfa.harvard.edu"><ievans@cfa.harvard.edu></a><br>
<strong>Cc: </strong>Bruno
<a class="moz-txt-link-rfc2396E" href="mailto:khelifi@apc.in2p3.fr"><khelifi@apc.in2p3.fr></a>; heig <a class="moz-txt-link-rfc2396E" href="mailto:heig@ivoa.net"><heig@ivoa.net></a><br>
<strong>Envoyé: </strong>vendredi 20 mars 2026 00:12
CET<br>
<strong>Sujet : </strong>Re: [Heig] Post running
meeting thoughts<br>
<br>
<div class="moz-cite-prefix">
<p><span style="color: #6699ff;">Dear Ian,</span></p>
<p><span style="color: #6699ff;">Sorry but I think
there is a misunderstanding of my intentions in
this discussion. I will start by answering your
conclusion before replying to some details</span></p>
<p> </p>
<blockquote>Sorry, but we need to to take full
advantage of the flexibility provided by the ObsCore
Recommendation as written to serve our science users
our science data, based on our familiarity with how
our science users want to access and use those data.
If the IVOA is unwilling to support the needs of
high-energy astrophysics, or at least of this very
large HEA data provider, then I want to hear that
stated directly and clearly by the IVOA Exec.</blockquote>
<span style="color: #ef2929;">T</span><span
style="color: #6699ff;">wo things : </span>
<p><span style="color: #6699ff;">First : I never,
never claimed that data which are important for
your group, for Chandra to expose should not be
exposed in the VO. I thought I was clear on that
several times. I only challenge the idea that
ObsCore is the right way for everything. And<u> I
proposed </u>several other solutions fully VO
consistent to do that (two DataLink solutions,
multiple tables with joins) in my post 4 weeks ago
on PR #35 (<a
href="https://github.com/ivoa/HighEnergyObsCoreExt/pull/35"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/ivoa/HighEnergyObsCoreExt/pull/35</a>).
It would be good to have you opinion about those.<br>
</span></p>
<p><span style="color: #6699ff;">Second : I am
interested in this project and insist to give
some advice because I think my experience in
building several VO protocols can be useful, as
well as my knowledge of the way several major data
providers such as CADC, GAVO, VizieR and others
implemented them and I hope the exec will not
consider I am doing any harm in discussing the
best way to expose data. <br>
</span></p>
<p><span style="color: #6699ff;"> </span></p>
<span style="color: #6699ff;">A few more details below
</span></div>
<div class="moz-cite-prefix"> </div>
<div class="moz-cite-prefix"> </div>
<div class="moz-cite-prefix">Le 02/03/2026 à 23:01, Dr.
Ian N. Evans a écrit :</div>
<blockquote>Dear Francois,
<div> </div>
<div>You are of course entitled to your opinion.
However, what you are arguing is in my view
inconsistent with the wording of the ObsCore
Recommendation, Version 1.1.</div>
<div> </div>
<div>As stated in section “1. Introduction”, of the
Recommendation “... The ability to pose a single
scientific query to multiple archives simultaneously
is a fundamental use case for the Virtual
Observatory. Providing a simple standard protocol
such as the one described in this document increases
the chances that a majority of the data providers in
astronomy will be able to implement the protocol,
thus allowing data discovery for almost all archived
astronomical observations.” That is exactly what we
are proposing here, with the scientific data
products required for high-energy astrophysics.</div>
</blockquote>
<span style="color: #6699ff;">---> I think many of
the products you store in your archive (as presented
in the document) are fundamentally not so far from
"flat fields", "dark images" "psf" in optical
astronomy, not to speak about various auxiliary data
in radio interferometry. I don't know any of the main
services exposing such response functions in the same
service than the main sky data. However most of them
provide ways to retrieve such response functions or
auxiliary data from fundamental sky data. Even The
HESS prototype is not exposing response functions as
independent products in ObsCore. Why Would Chandra be
so different that you need to use the ivoa.ObsCore
table to expose them instead of other related tables ?
</span></blockquote>
<div> </div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">For HESS we have not
(yet) expose the IRFs in VO because we could not without
the HE extension... simply ;)</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">The peculiarity of
the VHE data, compared to other field, is that we have
IRFs PER observation en general. This explains the need
of bundles.</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">Without it, we would
have 2 separated registries, implying to make 2 big
queries and then leave the user to recombine the data. I
think this is quite odd!</div>
<blockquote
style="margin: 0 0 0 .8em; border-left: 1px #ccc solid; padding-left: 1em;">
<blockquote>
<div> </div>
<div>Further, under section “2. Use cases”, the
Recommendation states “Support any type of science
data products (image, cube, spectrum, time series,
instrumental data, etc.).” All of our data products
satisfy this definition (and in fact instrument
responses are a perfect example of “instrumental
data”).</div>
</blockquote>
<span style="color: #6699ff;">--> Our understanding
of "instrumental data" was sky data at a very raw
level. And again there is absolutely no practice in
the VO to expose response functions in ObsCore</span></blockquote>
<div> </div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">IRFS are not raw
data, but products of high level. So info, almost the
same pipeline is used to make the event list and the
IRFs. The pipeline runs on observation raw data yo get
the event list and on the stimulated raw data yo get the
IRFs.</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">There are somehow at
the same calib level, which is not intuitive for
non-experts.</div>
<blockquote
style="margin: 0 0 0 .8em; border-left: 1px #ccc solid; padding-left: 1em;">
<blockquote>
<div>But you say “By science data we mean data where
we can detect some information of interest coming
from the sky.” Sorry, but YOU don’t get to tell US
what constitutes OUR “science data”. Section
“3.3.3. Observation and Observation Dataset” of the
Recommendation states “exactly what comprises an
“observation” is not well defined within astronomy
and is left up to the data provider to define for
their data.” for a reason. Science data products
vary dramatically from waveband to waveband, and
even within a waveband from instrument to instrument
depending on the physical mechanism used by the
detector. We consider instrument responses to be
“science data” and very much part of the
“observation dataset”.</div>
</blockquote>
<span style="color: #6699ff;">---> Ok if you don't
agree with my definition of science data which was
based on what I have seen in ObsTAP services so far,
let's talk about "sky data" instead. Again I am not
arrogant enough to force you to expose or not such and
such data, but I think I can give advice on where to
put them according to experience that all the
services have followed so far. What they have done is
consistent with the sentence in the same section
3.3.3 which reads "ObsTAP only directly supports the
description of science data products, i.e., data
products which contain science data having some
physical (spatial, spectral, temporal) coverage." </span></blockquote>
<div>Again, the HE is peculiar and naturally the past
definitions need updates.</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">For us, since 30
years, products like exposure is a science data. Not
intuitive again.</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">An exposure is by
definition deeply associated to a spatial, spectral and
temporal coverage. It permits to derive the expected
number of counts per forward-folding. Only HE (and
polarisation) are using this statistical technics to get
advanced products (like flux, spectrum, sed,
morphology).</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">So, indeed, this is
this new in IVOA, oldish for us. Definitions would need
to be updated, even we do not aim for the moment to use
ObsTAP standards. </div>
<blockquote
style="margin: 0 0 0 .8em; border-left: 1px #ccc solid; padding-left: 1em;">
<blockquote>
<div>Further down, section 3.3.3. Observation and
Observation Dataset” of the Recommendation states
“Two different approaches can be followed for
exposing the instrumental data from an observation.
One can either expose the individual science data
products resulting from the observation, all sharing
the same obs_id, or one can “package” the data
products and expose the package as a single complex
instrumental data product. ... Which approach is
best depends upon the anticipated scientific usage
and is up to the data provider to determine.” Again
this is sensibly up to the data provider because the
data provider is the one with the understanding of
how the provider’s science users access and use
their data.</div>
</blockquote>
<br>
<div><span style="color: #6699ff;">---> the same
section reads immediately after "If the data
products comprising an observation are exposed
individually then attributes such<br>
as the calibration level can vary for different data
products, e.g., the raw instrumental data as
observed might be level 1, a standard pipeline data
product might be level 2, and a custom
user-processed data product subsequently published
back to the archive might be level 3. All such data
products would share the same obs_id." Clearly this
sentence highlighted the intention that we were
building a protocol to expose "sky data" at
whatever calibration level and not for response
functions. Because I don't understand how we can
define a calibration level for a response function !<br>
</span></div>
</blockquote>
<div>You are hard with us! Again, without response
functions, no flux! Then, we do not need VO!</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">Either people accept
responses, either we leave IVOA.</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">Concerning the
definition os calibration level, I would like to stress
that he current definition is not coherent, not logical.
One can not derive a coherent data model from it. Taking
its definition to reject responses is a bit difficult to
read and to understand.</div>
<blockquote
style="margin: 0 0 0 .8em; border-left: 1px #ccc solid; padding-left: 1em;">
<blockquote>
<div> </div>
<div>You further posit that “If we don't do this and
extend the domain of ObsCore too much we force it to
become something else and to loose universality.”
On what basis do you make that assumption?
Certainly for Chandra data for example, our
instrument responses all map to a specific spatial,
spectral, and temporal coverage region on the sky.
The use cases in Appendix A of the HEA ObsCore
Extension almost all comprise queries that are based
on sky geometry, spectral, or temporal coverage,
with a few others based on obs_id.</div>
</blockquote>
<br>
<div><span style="color: #6699ff;">---> I think there
are two situations : </span></div>
<div><span style="color: #6699ff;"> </span></div>
<div><span style="color: #6699ff;"> -
either response function are estimated by exposing
the instrument to experimental flux in order to
provide a generic response function valid for a set
of observations (like we can do for a dark or a flat
or a spectral response). In that case the "obscore
characterisation" of this response function
considered as a dataproduct in ivoa.obscore table
would simply be borrowed from the sky data we would
relate to this response function. So mapping those
to a specific spatial, spectral, and temporal
coverage region on the sky is wrong because the
actual characterisation of the response dataset in
its own domain is probably very different. Appendix
A examples don't go against this interpretation of
how the obscore parameters are filled. This is why I
think we are losing universality in doing this. This
would be a very divergent</span><span
style="color: #6699ff;"> way of interpreting the
ObsCore characterisation parameters.<br>
</span></div>
<div><span style="color: #6699ff;"> -
or response function are directly estimated from
the sky data themselves via an analysis (I guess
this is how psf are generally obtained by estimating
the profile of a point source in the data). Then
the response is actually part of the description of
the sky data. It's level 4 characterisation ( 1
-> location, 2 -> bounds, 3 -> support, 4
-> functional response) It's not a different
product. </span></div>
<div><span style="color: #6699ff;">But the ivoa.obscore
table doesn't provide level 4 characterisation. If
desired it has to be provided by a link. <br>
</span></div>
<div><span style="color: #6699ff;"> In both cases
the binding </span><span style="color: #6699ff;">to
all response or auxiliary functions can be done
with the main sky dataset either by Classical
DataLink or by joining two different tables
(ivoa.obscore with any kind of description/access
table for response function) as I have explained
in my post in PR #35 (<a
href="https://github.com/ivoa/HighEnergyObsCoreExt/pull/35"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/ivoa/HighEnergyObsCoreExt/pull/35</a>)</span></div>
</blockquote>
<div> </div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">None is these 2
cases, and at the same times both. We have 4 IRFs, and
depending of its type we have a different process.</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">I can give you a
technical talk to have an idea how the 4 are generated.</div>
<blockquote
style="margin: 0 0 0 .8em; border-left: 1px #ccc solid; padding-left: 1em;">
<blockquote>
<div>You commented “When we designed ObsCore the
intention was to design a data model and an
associated tap table to expose science data.”, and
that is great. However, I doubt very much that the
design team included representation from the full
range of wavebands or complete representation of
different types of experiments, facilities, or
missions, and as a result the inputs that went into
building the standard (for example, what
constitutes “science data”) would have been
incomplete. You did an amazing job given the inputs
that you had! But standards evolve with time as
they become more complete, or they wither and die.
ObsCore is currently evolving based on needs from
radio, timing, and high-energy astrophysics, and
this should be celebrated because it means that the
standard is not withering and dying.</div>
</blockquote>
<span style="color: #6699ff;">---> The radio
extension was a way to provide a better description
of radio sky data themselves, not to add calibration
data, this is already a great evolution and the
additional parameters in the HeIG extension follow the
same philosophy. That's already a great change. And
for root ObsCore itself the characterisation datamodel
which is at the basis of it and the Obscore
specification itself were co-authored with people from
almost all domains including High Energy. The HESS
prototype doesn't provide access to response function
apart from the event list via the event-bundle product
type. So I don't think High energy use cases were
totally ignored in this work. </span></blockquote>
<div>See my reply about HESS above! We can't</div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs">Radio is not HE:
the comparison does not hold.</div>
<blockquote
style="margin: 0 0 0 .8em; border-left: 1px #ccc solid; padding-left: 1em;">
<blockquote>
<div>Sorry, but we need to to take full advantage of
the flexibility provided by the ObsCore
Recommendation as written to serve our science users
our science data, based on our familiarity with how
our science users want to access and use those data.
If the IVOA is unwilling to support the needs of
high-energy astrophysics, or at least of this very
large HEA data provider, then I want to hear that
stated directly and clearly by the IVOA Exec.</div>
</blockquote>
<br>
<div><span style="color: #6699ff;">---<span
style="font-size: small;">> </span> My final
question to you : "what is so wrong with combining
ObsCore and other adapted VO Technics to expose all
kind of data with more flexibility". </span></div>
</blockquote>
<div><span style="color: #6699ff;"> </span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;">Awfull, nightmare, complexity,
reduced maintability... should I continue?</span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;">We are not ready to support
this proposal, that will imply to reject the HE
specificities by the IVOA, illustrating the rigidity
of IVOA to new bands in the em spectrum and to new
messagers. But I know that this not your case. You
have just to realize that, without bundling IRFs to
events, any other technical solution will lead to
NEVER use the VO for the HE. We will then continue to
use standard web sites, leading to no interoperability
between all wavelengths and messengers of the IVOA,
which at the opposite of all EU and USA astrophysics
roadmaps.</span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;">Responses are MANDATORY and
just be delivered with the event list with the SAME
query.</span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;"> </span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;"> </span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;">Thanks again,</span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;"> </span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;">Cheers,</span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;">Bruno</span></div>
<div
style="font-size: 12pt; font-family: arial, helvetica, sans-serif; color: #000000;"
data-attr="forced_root_block_attrs"><span
style="color: #6699ff;"> </span></div>
<blockquote
style="margin: 0 0 0 .8em; border-left: 1px #ccc solid; padding-left: 1em;">
<p><span style="color: #6699ff;">I am ready to write a
section highlighting how this combination can be
done.</span></p>
<p><span style="color: #6699ff;">Best regards</span></p>
<p><span style="color: #6699ff;">François<br>
</span></p>
<blockquote>
<div> </div>
<div>Thanks,</div>
<div>—Ian</div>
<div><br>
<blockquote>
<div>On Feb 24, 2026, at 08:43, BONNAREL FRANCOIS
gmail via heig <a href="mailto:heig@ivoa.net"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true"><heig@ivoa.net></a>
wrote:</div>
<div>
<div>
<div class="moz-cite-prefix">
<div class="moz-forward-container">Dear
Bruno, dear Ian, all</div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">We come
back to this. </div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">There is
no doubt for us that VO should provide
ways to expose such things as "background
images" or in your case, Bruno, background
rate.</div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">Our
concern is about forcing ObsCore to be
this way to expose such datasets. </div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">When we
designed ObsCore the intention was to
design a data model and an associated tap
table to expose science data. </div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">By
science data we mean data where we can
detect some information of interest coming
from the sky. </div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">If we
don't do this and extend the domain of
ObsCore too much we force it to become
something else and to loose universality.
</div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">So
according to this general definition we
don't think response function belong to
the ObsCore domain. Advanced data products
are another issue we won't discuss them
today.</div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">Of course
there are plenty of ways to expose those
data and relate them with science data. VO
must for sure improve their description
and access modes</div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">DataLink
is the minimal method to make response
data accessible and relate them to
relevant science data but may present the
drawback to be a "two steps" process. If
direct access to response data is
required in a one step process we suggest
to explore the solution of defining the
DataLink response table as a TAP table in
order to allow JOINS with the ObsCore
science data table. </div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">But it is
true that the description provided by
DataLink is rather poor. </div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">So,
alternativeky, when needed, different
tables may be defined to describe response
function datasets and provide pointers to
them if necessary.</div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container"> A table
with ucd on most of the columns (existing
ucds or new ones to define) would already
provide a lot of interoperability between
services providing response data.</div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">
Moreover, defining "response function data
models" may provide more flexible and
accurate descriptions and acces methods.
Datamodels may be embedded in VOTables and
mapped to columns using utypes or
Mango+Mivot.</div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container"> We
think some sections of the HeiG note
should be revised in these directions.</div>
<div class="moz-forward-container"> We
are ready to help to do that. </div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container">François
with Mireille</div>
<div class="moz-forward-container"> </div>
<div class="moz-forward-container"> </div>
</div>
<div class="moz-cite-prefix"> </div>
<div class="moz-cite-prefix">Le 07/02/2026 à
19:15, Bruno Khelifi via heig a écrit :</div>
<blockquote>
<p>Hi all,</p>
<p>About "Background images and pixel masks
are not response-function data products",
maybe this is the case for X-rays. I won't
discuss it.</p>
<p>As reminder, the term `background` is
very generic and can be used for
everything. In gamma-ray astronomy, it is
from cosmic rays (it is not broken pixels,
that are handled much more earlier during
the raw data processing). In the GeV, TeV,
PeV, the background rate is without any
doubt an IRF!<br>
In contrary to X-rays, 3D analysis are
routinely made. For that the counts are
compared with the predicted counts, that
is the sum of the ones associated to gamma
rays and the ones associated to the
background rate, that are badly classified
events as gamma-rays (see our notes). The
estimation of the background rate can not
be done on the data, because they are
gamma rays everywhere in the field of view
for the galactic plane (ie one can not use
'OFF' regions). As reminder, the Fermi
bubble or eRosita bubble are going very up
in latitudes. Also, one can not use
simulations of cosmic rays to estimate the
background, because the resources would be
much too high and also because the
simulations badly reproduce the reality
(many studies made since decades show
that). We use a complex pipeline that
takes in input data, creates some
exclusion masks iteratively in 3D,
generates templates of rate in an
hypercube ( [X,Y] or theta, atmospheric
quality observable, optical efficiency of
our instruments, Zenith angles, azimuth
angles between of the geomagnetic effect
on the extensive air showers, and
reconstructed energy), curates the data to
handle empty bins and low statistics bin,
interpolates this hypercube template to
compute the observation-wise background
rate.</p>
<p>For the neutrino telescopes, real data
are also used. A specific pipeline is of
use also to compute the background rate.</p>
<p>So, one should keep without any doubt the
background rate as data product!</p>
<p>Best,<br>
Bruno</p>
<br>
<div class="moz-cite-prefix">Le 04/02/2026 à
20:38, Dr. Ian N. Evans via heig a écrit :</div>
<blockquote>Dear Francois,
<div> </div>
<div>I consider the arf, rmf, and psf to
be response-function data products.
Background images and pixel masks are
not response-function data products -
they are determined directly from the
observation event list similarly to a
total counts image. Bad pixel is a
region data product, but it’s something
of a gray area since it’s a combination
of known bad pixel regions plus bad
pixel regions derived directly from the
observation event list.</div>
<div> </div>
<div>For the Chandra Source Catalog (CSC)
prototype, at least initially we plan to
expose all of the data products directly
to demonstrate that the extension
provides the flexibility that we need.
However in production, we likely would
not expose all of the data products
individually but rather combine some of
them with the event lists as event
bundles (at least for the individual
observation full-field data product
set). We would want to expose the
individual observation event lists
individually, but might choose for
example to construct an event bundle
that exposes (at least) the event list,
bad pixel regions, aspect histogram, and
possible aspect solution as a bundle
since there is very little use for the
latter 3 types of data product without
the event list.</div>
<div> </div>
<div>While tying associated and derived
data products to an event list in an
event bundle seems sensible for
individual observations, our experience
is that this isn’t appropriate for the
CSC advanced data products. Since CSC
2.0 was released we have had millions of
catalog data product downloads and
surveyed our user base as to data
product usage.</div>
<div> </div>
<div>The typical usage patterns for the
CSC advanced data products are different
from the typical usage patterns for
individual X-ray observation data.</div>
<div> </div>
<div>For the latter the user typically
downloads the event list and ancillary
data products (such as responses or
other data products that can be used to
build responses) as a set, and then
performs data analysis steps directly on
the event list using the ancillary data
products, often after applying
spatial/spectral/temporal filters to the
data. Event bundles facilitate this
usage.</div>
<div> </div>
<div>For the CSC advanced data products
the usage patterns are quite different.
Many (most) of these advanced data
products are derived from multiple (in
some cases hundreds) observations.
Typically the users aren’t interested
in performing data analysis steps on the
event lists themselves, and often aren’t
interested in knowing which
observation(s) they are derived from (at
least not from the perspective of having
to perform a data query). They just
want (e.g.) all the spectra (or light
curves, or photometry MPDFs, or ...) in
a certain region of the sky, or in a
given time range, etc. And given the
data volume that’s all they want. Maybe
they’ll come back later and ask for a
subset of additional data products after
they’ve performed some preliminary
analyses on those data products, but
they don’t want those up front.</div>
<div> </div>
<div>
<div>Based on these usage patterns, I
think we will likely want to expose
the remaining CSC data products
individually.</div>
</div>
<div> </div>
<div>Thanks,</div>
<div>—Ian</div>
<div>
<div><br>
<blockquote>
<div>On Jan 27, 2026, at 09:52,
BONNAREL FRANCOIS gmail via heig <a
href="mailto:heig@ivoa.net"
target="_blank"
rel="noopener noreferrer"
moz-do-not-send="true"><heig@ivoa.net></a>
wrote:</div>
<div>
<div>
<p>Dear all,</p>
<p>After the meeting last week,
I was still thinking about
what the Chandra prototype
could look like</p>
<p>For the Paris HESS prototype,
I get the idea since a couple
of years now. </p>
<p>Trying to understand what the
CSC data products could be I
came back to Ian's Malta
interop presentation.</p>
<p>I copy/paste here one of the
slides where some of these
products are described.</p>
<p>Before trying to define
dataproduct_type vocabulary
terms for those products I am
wondering if we really need to
expose all this data directly
in</p>
<p>an ObsTAP service.</p>
<p>For example background
images, psf, pixel mask, bad
pixel regions, ARF belong to
the "response functions"
category if I'm not mistaking.
</p>
<p>They probably are attached to
a photon event list or an
image or ....</p>
<p>Including all this in the
main ObsCore table will
overload it very
heterogeneously. Some of these
response functions will be
similar to what we get in
other domains (psf) some will
be very different and specific
to Xray.</p>
<p>I understood that the
spatial, spectral, time
characterization of these
specific products could be
borrowed from the observation
they are associated with. It's
ok but is that useful ?</p>
<p>For accessing these response
functions I can imagine 4
solutions which all will have
the advantage to let the
OBsTAp service be focused on
measurements obtained from the
sky at whatever calib level.</p>
<p> 1 ) the photon event list
and response functions are
gathered together in the same
tar or archive file (or MEF)
which is typed as an
event-bundle. Direct access to
this bundle from Obstap
access_url is then easy. It's
the client task to figure out
what to do with the content of
the bundle.</p>
<p> 2 ) the various response
material is kept as a set of
individual products. All are
associated to an event list or
an image or a spectrum. In
that case ObsTAP point to a
datalink response which lists
all these different products.
The semantics FIELD writes
calibration or response
function. Content_qalifier
FIELD writes the very nature
of the product.</p>
<p> 3 ) the DataLink reponse
content may be organized as a
TAP table. It's then possible
to query at the same time the
ObsTAP table and the
DataLink-like table by a join
on
ObsCore/obs_publisher_did-DataLink/ID</p>
<p> 4 ) if we need a more
detailed description of the
response products to help
discover and select them we
could imagine creating a
specific "response product"
table following a specific
datamodel as proposed by
Mireille in her Gorlitz
presentation. This will allow
to attach specific eg :</p>
<p> - time range to a psf
or</p>
<p> - specific release date
and description to an arf or a
bad pixel map</p>
<p> -.... </p>
<p> Natural join on
obs_publisher_did in both
tables will allow to query
those table at the same time
with selection criteria from
both.</p>
<p> Cheers</p>
<p>François</p>
<p> </p>
<p> </p>
<p> </p>
<p><span
id="cid:part1.601HUn9S.HmZf1KQZ@gmail.com"><ulnvpjC4zXtPT0zn.png></span></p>
</div>
-- <br>
heig mailing list<br>
<a href="mailto:heig@ivoa.net"
target="_blank"
rel="noopener noreferrer"
moz-do-not-send="true"
class="moz-txt-link-freetext">heig@ivoa.net</a><br>
<a
href="https://www.google.com/url?q=https://www.google.com/url?q%3Dhttp://mail.ivoa.net/mailman/listinfo/heig%26source%3Dgmail-imap%26ust%3D1770130364000000%26usg%3DAOvVaw1NuTRL3a6Ib8NM2g8f0TM8&source=gmail-imap&ust=1772545426000000&usg=AOvVaw1VPiNz8zudrIQeUMJoRNTa"
target="_blank"
rel="noopener noreferrer"
moz-do-not-send="true">https://www.google.com/url?q=http://mail.ivoa.net/mailman/listinfo/heig&source=gmail-imap&ust=1770130364000000&usg=AOvVaw1NuTRL3a6Ib8NM2g8f0TM8</a></div>
</blockquote>
</div>
<br>
<div>
<div
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; background-color: #ffffff; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-family: 'arial'; font-size: 9.5pt; font-style: normal; font-weight: bold; letter-spacing: normal; text-transform: none; white-space: pre-wrap; word-spacing: 0px; text-decoration: none; vertical-align: baseline;">—</span></div>
<div
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; background-color: #ffffff; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-family: 'arial'; font-size: 9.5pt; font-style: normal; font-weight: bold; letter-spacing: normal; text-transform: none; white-space: pre-wrap; word-spacing: 0px; text-decoration: none; vertical-align: baseline;"> Dr. Ian Evans</span></div>
<div
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; background-color: #ffffff; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-family: Arial;"><span
style="font-size: 12.666666984558105px; white-space: pre-wrap;"><strong>Astrophysicist</strong></span></span></div>
<div
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; background-color: #ffffff; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-family: Arial;"><span
style="font-size: 12.666666984558105px; white-space: pre-wrap;"><strong>Chandra X-ray Center</strong></span></span></div>
<div
style="font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; background-color: #ffffff; font-family: '-webkit-standard'; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-size: 9.5pt; font-family: 'arial'; background-color: #ffffff; font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">Center for Astrophysics | Harvard & Smithsonian</span></div>
<div
style="font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; background-color: #ffffff; font-family: '-webkit-standard'; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-size: 9.5pt; font-family: 'arial'; vertical-align: baseline; white-space: pre-wrap;">Office: (617) 496 7846 | Cell: (617) 699 5152</span></div>
<div
style="font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; background-color: #ffffff; font-family: '-webkit-standard'; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-family: 'arial'; font-size: 9.5pt; white-space: pre-wrap;">60 Garden Street | MS 81 | Cambridge, MA 02138</span></div>
<span
id="cid:part1.0IwoKJG8.kaEQ20yc@gmail.com"><PastedGraphic-2.png></span>
<span
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;"><span
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; float: none; display: inline !important;"><br>
</span></span>
<div
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;"><span
style="letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;"><span
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; float: none; display: inline !important;"> </span></span></div>
<span
id="cid:part2.SAknuefi.EfTfiBys@gmail.com"><PastedGraphic-3.png></span>
<span
style="font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; font-family: Arial; font-size: small;"><u
style="letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><span
lang="EN"
style="line-height: 14.566667556762695px;"><a
href="https://www.google.com/url?q=http://cfa.harvard.edu/&source=gmail-imap&ust=1772545426000000&usg=AOvVaw0uFI_1KoCUvDnmcfLwnZWl"
target="_blank"
rel="noopener noreferrer"
moz-do-not-send="true">cfa.harvard.edu</a></span></u><span
lang="EN"
style="letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; line-height: 14.566667556762695px;"> | <u><a
href="https://www.google.com/url?q=http://cfa.harvard.edu/facebook&source=gmail-imap&ust=1772545426000000&usg=AOvVaw02xqYrC2mM2M8D3GD_fAAy"
target="_blank"
rel="noopener noreferrer"
moz-do-not-send="true">Facebook</a></u> | <u><a
href="https://www.google.com/url?q=http://cfa.harvard.edu/twitter&source=gmail-imap&ust=1772545426000000&usg=AOvVaw3ilzQjksdV2EyBorR2VpR3"
target="_blank"
rel="noopener noreferrer"
moz-do-not-send="true">Twitter</a></u> | <u><a
href="https://www.google.com/url?q=http://cfa.harvard.edu/youtube&source=gmail-imap&ust=1772545426000000&usg=AOvVaw39-gxMDL8maWEsAwabab0W"
target="_blank"
rel="noopener noreferrer"
moz-do-not-send="true">YouTube</a></u></span><span
lang="EN"
style="letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; line-height: 14.566667556762695px;"> | <u><a
href="https://www.google.com/url?q=http://cfa.harvard.edu/newsletter&source=gmail-imap&ust=1772545426000000&usg=AOvVaw1GftJaRGdajEXnp9-teyn8"
target="_blank"
rel="noopener noreferrer"
moz-do-not-send="true">Newsletter</a></u></span></span></div>
</div>
</blockquote>
<pre class="moz-signature">--
Bruno Khelifi
Physicist at CNRS (laboratory APC, Paris)
Phone: +33.1.57.27.61.58 - Fax: +33.1.57.27.60.71
APC, IN2P3/CNRS - Universite de Paris Cite
</pre>
</blockquote>
<p> </p>
</div>
-- <br>
heig mailing list<br>
<a href="mailto:heig@ivoa.net" target="_blank"
rel="noopener noreferrer"
moz-do-not-send="true"
class="moz-txt-link-freetext">heig@ivoa.net</a><br>
<a
href="https://www.google.com/url?q=http://mail.ivoa.net/mailman/listinfo/heig&source=gmail-imap&ust=1772545426000000&usg=AOvVaw1CKWt3qicSCcjAbQuwDfB1"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">https://www.google.com/url?q=http://mail.ivoa.net/mailman/listinfo/heig&source=gmail-imap&ust=1772545426000000&usg=AOvVaw1CKWt3qicSCcjAbQuwDfB1</a></div>
</blockquote>
</div>
<br>
<div>
<div
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; color: #000000; background-color: #ffffff; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="color: #000000; font-family: 'arial'; font-size: 9.5pt; font-style: normal; font-weight: bold; letter-spacing: normal; text-transform: none; white-space: pre-wrap; word-spacing: 0px; text-decoration: none; vertical-align: baseline;">—</span></div>
<div
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; color: #000000; background-color: #ffffff; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="color: #000000; font-family: 'arial'; font-size: 9.5pt; font-style: normal; font-weight: bold; letter-spacing: normal; text-transform: none; white-space: pre-wrap; word-spacing: 0px; text-decoration: none; vertical-align: baseline;"> Dr. Ian Evans</span></div>
<div
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; color: #000000; background-color: #ffffff; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-family: Arial;"><span
style="font-size: 12.666666984558105px; white-space: pre-wrap;"><strong>Astrophysicist</strong></span></span></div>
<div
style="font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; color: #000000; background-color: #ffffff; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-family: Arial;"><span
style="font-size: 12.666666984558105px; white-space: pre-wrap;"><strong>Chandra X-ray Center</strong></span></span></div>
<div
style="font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; color: #000000; background-color: #ffffff; font-family: '-webkit-standard'; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-size: 9.5pt; font-family: 'arial'; background-color: #ffffff; font-weight: bold; vertical-align: baseline; white-space: pre-wrap;">Center for Astrophysics | Harvard & Smithsonian</span></div>
<div
style="font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; color: #000000; background-color: #ffffff; font-family: '-webkit-standard'; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-size: 9.5pt; font-family: 'arial'; vertical-align: baseline; white-space: pre-wrap;">Office: (617) 496 7846 | Cell: (617) 699 5152</span></div>
<div
style="font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; color: #000000; background-color: #ffffff; font-family: '-webkit-standard'; line-height: 1.2; margin-top: 0pt; margin-bottom: 0pt;"><span
style="font-family: 'arial'; font-size: 9.5pt; white-space: pre-wrap;">60 Garden Street | MS 81 | Cambridge, MA 02138</span></div>
<img src="cid:part1.58Hi6xz7.dHapPX06@apc.in2p3.fr"
width="263" alt="PastedGraphic-2.png"
doc="PastedGraphic-2.png" class=""> <span
style="color: #000000; font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;"><span
style="color: #000000; font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; float: none; display: inline !important;"><br>
</span></span>
<div
style="color: #000000; font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;"><span
style="letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;"><span
style="color: #000000; font-family: 'monaco'; font-size: 12px; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; float: none; display: inline !important;"> </span></span></div>
<img src="cid:part2.qhjhQdAv.lOxOiMl8@apc.in2p3.fr"
width="111" alt="PastedGraphic-3.png"
doc="PastedGraphic-3.png" class=""> <span
style="color: #000000; font-style: normal; font-weight: normal; letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; font-family: Arial; font-size: small;"><u
style="letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><span
lang="EN"
style="line-height: 14.566667556762695px;"><a
href="http://cfa.harvard.edu/"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">cfa.harvard.edu</a></span></u><span
lang="EN"
style="letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; line-height: 14.566667556762695px;"> | <u><a
href="http://cfa.harvard.edu/facebook"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">Facebook</a></u> | <u><a
href="http://cfa.harvard.edu/twitter"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">Twitter</a></u> | <u><a
href="http://cfa.harvard.edu/youtube"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">YouTube</a></u></span><span
lang="EN"
style="letter-spacing: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; line-height: 14.566667556762695px;"> | <u><a
href="http://cfa.harvard.edu/newsletter"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">Newsletter</a></u></span></span></div>
</blockquote>
<p> </p>
</blockquote>
</div>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<pre class="moz-signature" cols="72">--
Bruno Khelifi
Physicist at CNRS (laboratory APC, Paris)
Phone: +33.1.57.27.61.58 - Fax: +33.1.57.27.60.71
APC, IN2P3/CNRS - Universite de Paris Cite
</pre>
</body>
<lt-container></lt-container>
</html>