From blew w astro.uni.torun.pl Wed Nov 9 06:03:00 2005 From: blew w astro.uni.torun.pl (Bartosz Lew) Date: Wed, 9 Nov 2005 06:03:00 +0100 (MET) Subject: [Shape-univ] couple of comments on the pixelization schemes Message-ID: Hi Boud, I've been wondering about the optimal pixelization scheme of the sphere a couple of weeks ago and since I've send to you my own implementation of the Healpix pixelization scheme written (generally) in C (according to astro-ph/0409533) but compatible with GNU c++ compiler here I'd like to comment on some comments that can be found in the source code. And since you don't like private, closed conversations I also cc this letter to shape-univ. 1) First of all healpix is not stupid :)))) - it's cool because pixels have the same area which is not always the case (e.g.. quad-cube pixelization used with COBE data), because it's hierarchical and isolatitude of course, however the first and the last features are also common in other pixelization schemes. 1.1) But also very important thing is that it is more less "equi-angular" - i.e. the angular distance from pixel to pixel is more less constant. But obviously the exact "equi-angular" solution does not exist. 2) Now the my CPEDS library for doing useful stuff - and especially the pixelization.c has more useful functions so probably I should update the version I've send to you. i.e. - conversions from RING to NESTED and vice versa - calculation of ring given pixel and vice versa (in both nested and ring orderings) - estimated pixel size (maybe not that useful) since it may be probably just as well estimated from 4PI/N_pix. 3) The main point I wanted to come up with the new idea for pixelization scheme was the thing I addressed in point 1.1. But also the following 3 drawbacks of this scheme, namely: 3.1) the pixel shape dramatically varies from pixel to pixel. this is what I didn't like because of e.g. CMB lensing studies where the morphology at small scales would be very important - but of course this can be overcome with sufficiently oversampling the pixelization by increasing the Nside parameter to meet the Nyquist conditions. 3.2) the number of pixels in a ring does NOT gradually rises with increasing \theta (in spherical system definition consistent with HEALPIX - i.e. theta = 0 at North pole). Instead it only rises in the top (bottom) part of the north (south) polar region. This is certainly unnatural thing. since all the latitudes in equatorial (roughly from 41 deg to 180-41 deg regions are represented by the same amount of pixels in longitude) !! This is not the case e.g.. in he GLESP (Gauss-Legendre) or Igloo pixelization schemes. 3.3) It has an axial symmetry (since it has a poles equator, rings, etc). And why the CMB sky should know anything about the symmetry ? In particular why should it have an axial symmetry ? So naturally the solution would evolve into direction of platonic forms like tetrahedron, cube, ... oops it ends at icosahedron. And since we need a pixelization with number of pixels something like few Mpixels the 20 pixels of icosahedron is not enough. My idea of tetrahedron based pixelization system was just driven from this point of view that there should be no preferred directions in the sky. The system would gain higher resolution by looking for directions equally separated from neighboring directions (initially defined by axis of tetrahedron). This concept fails, of course because such a solution does not exist. Max Tegmark also went in this direction inventing the icosahedron pixelization system which is the next step after the quad-cube system, but each triangle is divided in other way. Anyway, at this time I see no point of terrible importance to force the idea of the tetrahedron pixelization system so I drop this case. rather it would be interesting to implement other pixelizations systems into the isolat packet. pozdr, Bartek From boud w astro.uni.torun.pl Wed Nov 9 13:28:21 2005 From: boud w astro.uni.torun.pl (Boud Roukema) Date: Wed, 9 Nov 2005 13:28:21 +0100 (CET) Subject: [Shape-univ] couple of comments on the pixelization schemes In-Reply-To: References: Message-ID: Hi Bartek, all, :) On Wed, 9 Nov 2005, Bartosz Lew wrote: > I've been wondering about the optimal pixelization scheme of the sphere a > couple of weeks ago and since I've send to you my own implementation of > the Healpix pixelization scheme written (generally) in C (according to > astro-ph/0409533) but compatible with GNU c++ compiler here I'd like to > comment on some comments that can be found in the source code. > > And since you don't like private, closed conversations I also cc this > letter to shape-univ. Good :). That puts more pressure on me to integrate your code into the "isolat" package. :) > 1) First of all healpix is not stupid :)))) - it's cool because pixels Of course - IMHO we all agree on this. It's cool. :) > have the same area which is not always the case (e.g.. quad-cube > pixelization used with COBE data), because it's hierarchical and > isolatitude of course, however the first and the last features are also > common in other pixelization schemes. > > 1.1) But also very important thing is that it is more less "equi-angular" > - i.e. the angular distance from pixel to pixel is more less constant. But > obviously the exact "equi-angular" solution does not exist. Hmm. AFAIK that's correct. > 2) Now the my CPEDS library for doing useful stuff - and especially the > pixelization.c has more useful functions so probably I should update the > version I've send to you. i.e. > - conversions from RING to NESTED and vice versa > - calculation of ring given pixel and vice versa (in both nested and ring > orderings) > - estimated pixel size (maybe not that useful) since it may be probably > just as well estimated from 4PI/N_pix. OK > 3) The main point I wanted to come up with the new idea for pixelization > scheme was the thing I addressed in point 1.1. But also the following 3 > drawbacks of this scheme, namely: > > 3.1) the pixel shape dramatically varies from pixel to pixel. this is what > I didn't like because of e.g. CMB lensing studies where the morphology at > small scales would be very important - but of course this can be overcome > with sufficiently oversampling the pixelization by increasing the Nside > parameter to meet the Nyquist conditions. Well, oversampling is what i assume is always done. > 3.2) the number of pixels in a ring does NOT gradually rises with > increasing \theta (in spherical system definition consistent with HEALPIX > - i.e. theta = 0 at North pole). Instead it only rises in the top (bottom) > part of the north (south) polar region. This is certainly unnatural > thing. since all the latitudes in equatorial (roughly from 41 deg to > 180-41 deg regions are represented by the same amount of pixels in > longitude) !! This is not the case e.g.. in he GLESP (Gauss-Legendre) or > Igloo pixelization schemes. > > 3.3) It has an axial symmetry (since it has a poles equator, rings, etc). > And why the CMB sky should know anything about the symmetry ? In > particular why should it have an axial symmetry ? So naturally the > solution would evolve into direction of platonic forms like tetrahedron, > cube, ... oops it ends at icosahedron. And since we need a pixelization > with number of pixels something like few Mpixels the 20 pixels of > icosahedron is not enough. My idea of tetrahedron based pixelization > system was just driven from this point of view that there should be no > preferred directions in the sky. The system would gain higher resolution > by looking for directions equally separated from neighboring directions > (initially defined by axis of tetrahedron). This concept fails, of course > because such a solution does not exist. Well, i agree with the motivation. > Max Tegmark also went in this direction inventing the icosahedron > pixelization system which is the next step after the quad-cube system, but > each triangle is divided in other way. > > Anyway, at this time I see no point of terrible importance to force the > idea of the tetrahedron pixelization system so I drop this case. rather it > would be interesting to implement other pixelizations systems into the > isolat packet. Do you implementing "existing" pixelisation systems? Well, i see nothing against it, i just don't see it how it would be useful in practice. Unless someone is going to reanalyse the *raw* data of WMAP or Planck - and i mean the really raw data, before it has been converted to the healpix projection/pixelisation - then *re*formatting an observational map from the healpix system to a new system is only going hide the effects (if any) of the healpix system, it's not going to remove them. (And moreover, it will necessarily introduce some additional numerical error.) Hmm... However, given that a lot of interest is in the smaller angular scales, the question is how much different pixelisation methods could cause wrong conclusions to be made... If you're going to use these different systems e.g. on a hypothetical data set, which is projected/pixelised in different ways, then that could potentially be an interesting paper. :) OK, i'll put your isolat addition higher up in my todo list :) pozdr boud From Bartosz.Lew w astri.uni.torun.pl Thu Nov 10 04:07:25 2005 From: Bartosz.Lew w astri.uni.torun.pl (Bartosz Lew) Date: Thu, 10 Nov 2005 04:07:25 +0100 (CET) Subject: [Shape-univ] couple of comments on the pixelization schemes In-Reply-To: References: Message-ID: Hi Boud, everyone > > Anyway, at this time I see no point of terrible importance to force the > > idea of the tetrahedron pixelization system so I drop this case. rather it > > would be interesting to implement other pixelizations systems into the > > isolat packet. > > Do you implementing "existing" pixelisation systems? > > Well, i see nothing against it, i just don't see it how it would be useful > in practice. Unless someone is going to reanalyse the *raw* data of WMAP > or Planck - and i mean the really raw data, before it has been converted to > the healpix projection/pixelisation - then *re*formatting an observational > map from the healpix system to a new system is only going hide the effects > (if any) of the healpix system, it's not going to remove them. (And moreover, > it will necessarily introduce some additional numerical error.) unless of course you want to simulate your own maps to do various stuff - the you can do it in different pixelization systems and see the difference in power spectrum, bispectrum, Minkowski functionals etc. for example see: astro-ph/0305537 for differences in power spectrum and now I see another related paper which a haven't read yet: astro-ph/0501494 besides I think there are methods for repixelizing from one scheme to another which are more less optimall - free of the effects you mentioned but I don't know the details. > > > Hmm... However, given that a lot of interest is in the smaller angular > scales, the question is how much different pixelisation methods could > cause wrong conclusions to be made... > > If you're going to use these different systems e.g. on a hypothetical data > set, which is projected/pixelised in different ways, then that could potentially > be an interesting paper. :) > well, mayebe this isn't a big science :) but it's of basic importance. However Healpix has been choosen as a pixelization system for PLANCK data so probably they know what they are doing. > OK, i'll put your isolat addition higher up in my todo list :) well it's not urgent, take you time :) and one more comment about the fortran versus c++. I don't know why such a situation is but it seems to me that the scientific society have choosen fortran (90) as a basic programming language (eg. healpix, icosahedron, partially glesp pix. systems, WMAP likelihood pipeline stuff, cmbfast -- all fortran ). Maybe the point is that according to my last quick findings fortran is a little bit faster to just faster :) evern if applied various optimalization flags in c++ compiler. But for people who program in c++ (like me) the situation is not comfortable, hence another motivation for writting implementations in c/c++. (eg. cmbEASY was written in c++ AFAIR). pozdr. Bartek From boud w astro.uni.torun.pl Fri Nov 18 13:57:12 2005 From: boud w astro.uni.torun.pl (Boud Roukema) Date: Fri, 18 Nov 2005 13:57:12 +0100 (CET) Subject: [Shape-univ] CosmoPl meeting Jan/Feb 2006 Message-ID: Cześć cosmo-spotka, Marek Biesiada from Katowice is interested in helping organise a small, informal 2-day cosmology meeting in Jan/Feb 2006. The main idea is to get together the different Polish cosmology people from Szczecin, Toruń, Kraków, Katowice, Lublin, Warsaw and hopefully maybe also some visitors from Czechy, Potsdam, Estonia, ... Anyway, here's the twiki page: http://cosmo.torun.pl/cgi-bin/twiki/view/Cosmo/CosmPlMeeting2006 Please join cosmo-spotka@ http://cosmo.torun.pl/mailman/listinfo/cosmo-spotka or else read the twiki page regularly if you're interested in helping organise (scientifically + locally) or participate in this meeting. Some time soon, we should send an invitation out to cosmo-pl@ - but IMHO we should keep cosmo-pl@ as a low volume list (many people are subscribed). Anyone interested in this meeting should join cosmo-spotka. pozdr boud From szachula w astro.uni.torun.pl Tue Nov 22 21:28:40 2005 From: szachula w astro.uni.torun.pl (Agnieszka Szaniewska) Date: Tue, 22 Nov 2005 21:28:40 +0100 (MET) Subject: [Shape-univ] CosmoPl meeting Jan/Feb 2006 In-Reply-To: Message-ID: Hi everyone, I am a new person on Shape-univ, precisely I am a PhD student (centrum Astronomii) . Anyway, I am interested in helping organise (and participating of course) in cosmology meeteing in Jan/Feb 2006. Pozdrawiam, Agnieszka On Fri, 18 Nov 2005, Boud Roukema wrote: > Cze�� cosmo-spotka, > > Marek Biesiada from Katowice is interested in helping organise a small, > informal 2-day cosmology meeting in Jan/Feb 2006. The main idea is to get together > the different Polish cosmology people from Szczecin, Toru�, Krak�w, Katowice, > Lublin, Warsaw and hopefully maybe also some visitors from Czechy, Potsdam, > Estonia, ... > > Anyway, here's the twiki page: > http://cosmo.torun.pl/cgi-bin/twiki/view/Cosmo/CosmPlMeeting2006 > > Please join cosmo-spotka@ > > http://cosmo.torun.pl/mailman/listinfo/cosmo-spotka > > or else read the twiki page regularly if you're interested in helping > organise (scientifically + locally) or participate in this meeting. > > Some time soon, we should send an invitation out to cosmo-pl@ - but IMHO we > should keep cosmo-pl@ as a low volume list (many people are subscribed). Anyone > interested in this meeting should join cosmo-spotka. > > pozdr > boud > > _______________________________________________ > Shape-univ mailing list > Shape-univ w cosmo.torun.pl > http://cosmo.torun.pl/mailman/listinfo/shape-univ > From boud w astro.uni.torun.pl Fri Nov 25 09:22:50 2005 From: boud w astro.uni.torun.pl (Boud Roukema) Date: Fri, 25 Nov 2005 09:22:50 +0100 (CET) Subject: [Shape-univ] bede kilka minuty spozniony dzis Message-ID: Przepraszam, trochę zadużo spałem dziś - idę do Piwnic z autobusem o 10.00g - tzn będę wykład od ok. 10.40g. pozdr boud From boud w astro.uni.torun.pl Wed Nov 30 14:42:20 2005 From: boud w astro.uni.torun.pl (Boud Roukema) Date: Wed, 30 Nov 2005 14:42:20 +0100 (CET) Subject: [Shape-univ] reading matter - nonbaryonic dark matter In-Reply-To: <20051128152745.37DE73031DB@poczta.interia.pl> References: <20051128152745.37DE73031DB@poczta.interia.pl> Message-ID: Witam wszystkim na shape-univ, Mamy ktoś nowy, który interesuje się w kosmologii :) - Łukasz zaczyna licencjat o ciemnej materii - witam Łukasz :). Dodawałem nową sekcję do twiki: http://adjani.astro.uni.torun.pl/cgi-bin/twiki/view/Cosmo/NonBaryonicDarkMatter#Review_Introduction_papers_on_No Proszę popraw błędy, albo daj lepszy artykułow, itd. pozdr boud Review/Introduction papers on Non-Baryonic Dark Matter problem big-bang nucleosynthesis (BBN), e.g. Steigmann AstroPh:0511534 \Rightarrow \Omega_{nonbaryonic} \sim 0.25 WIMPS * AstroPh:0402045 Martin Rees - recent, quick and short * AstroPh:0506676 pages 5,6,7 Paul Frampton - recent, quantified, quick, short summary * AstroPh:0403064 Paul Gondolo - recent, in-depth introduction MACHOS * recent MACHO articles: http://arxiv.org/find/astro-ph/1/ti:+machos/0/1/0/all/0/1 * MACHO debate: are the MW microlensing events only due to known stellar populations? o Evans & Belokurov, 2004, RIP: The Macho Era (1974-2004) AstroPh:0411222 vs o Griest & Thomas 2004 Contamination in the MACHO dataset and the puzzle of LMC Microlensing AstroPh:0412443 brown dwarfs * brown dwarfs are baryonic: they cannot explain \Rightarrow \Omega_{nonbaryonic} \sim 0.25 pierwotny czarny dziury - primordial black holes * Afshordi et al. AstroPh:0302035 Primordial Black Holes as Dark Matter: The Power Spectrum and Evaporation of Early Structures