From serenipaolo at yahoo.com Tue Jan 2 11:23:53 2024 From: serenipaolo at yahoo.com (Paolo Sereni) Date: Tue, 2 Jan 2024 16:23:53 +0000 (UTC) Subject: [AstroPy] Question on the coordinates of the sun: Hour angle instead of RA, how? References: <887999441.7520975.1704212633605.ref@mail.yahoo.com> Message-ID: <887999441.7520975.1704212633605@mail.yahoo.com> Hello everyone, first a couple of words about myself: I am a hobby astronomer and I'm presently teaching to future physics school-teachers. In my lesson I would like to introduce some very basics concepts of astronomy and I use Stellarium as additional tool. My goal is to develop enough material to be able to understand and build a sun dial. Since I'm also giving an introductory course in python programming, astropy seems to be the perfect library to perform some calculations. Specifically, I would like to be able to calculate for any given day an time the *Hour Angle* and Declination of the Sun as seen from Salzburg, where I live and teach. Looking at the impressive documentation of astropy I found two very promising examples, however both of them calculate RA (right ascension) and DEC instead of HA (Hour Angle) and DEC. I do not know how to solve this problem. I do not know whether I have to use another "frame" (?) or if I have to "manually" correct using the Hour Angle of the first point of Aries (something like HA = HA_Aries + RA)...???? ( in this case where/how can I find HA_Aries?)??Here the code of the two examples:-------------------------------------------#Variant 1import astropy.units as u from astropy.coordinates import AltAz, EarthLocation, SkyCoordfrom astropy.time import Timefrom astropy import coordinates Salzburg = EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m)#Salzburg time is UTC +1 we need to correct ismy_time = "2023-12-30T12:00:00"my_t = Time(my_time)sun_coordinates = coordinates.get_sun(my_t)print(type(sun_coordinates))print(sun_coordinates)print("\n\nCoordinates of the sun:")print("\tright ascension:? " + str(sun_coordinates.ra))print("\tdeclination:? ? ?" + str(sun_coordinates.dec))print("\tdistance:? ? ? ? ?" + str(sun_coordinates.distance)) ---------------------------------------------------#Variant 2from astropy.coordinates import EarthLocation, Longitude, SkyCoord, get_body, solar_system_ephemerisfrom astropy.time import Timeimport astropy.units as u obs_time = Time('2023-12-30T12:00:00', format='isot', scale='utc')location=EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m)solar_system_ephemeris.set('de432s')sun = get_body('sun', obs_time, location)print("sun: " + str(sun))print("\n\n")aries = SkyCoord(0*u.deg, 0*u.deg, frame='geocentrictrueecliptic', obstime=obs_time, equinox=obs_time)RA = Longitude(sun.itrs.spherical.lon - aries.itrs.spherical.lon)print("RA ="? + str(RA))dec = sun.itrs.spherical.latprint("DEC = " + str(dec)) ------- Which variant would you recommend me? Any help for obtaining HA will be greatly appreciated. Thank you very much and happy 2024! Cheers, Paolo Sereni -------------- next part -------------- An HTML attachment was scrubbed... URL: From brewer at astro.umass.edu Tue Jan 2 12:29:57 2024 From: brewer at astro.umass.edu (Michael Brewer) Date: Tue, 2 Jan 2024 12:29:57 -0500 Subject: [AstroPy] Question on the coordinates of the sun: Hour angle instead of RA, how? In-Reply-To: <887999441.7520975.1704212633605@mail.yahoo.com> References: <887999441.7520975.1704212633605.ref@mail.yahoo.com> <887999441.7520975.1704212633605@mail.yahoo.com> Message-ID: Paolo, The simplest way to do this is to use the HADec frame introduced in Astropy 5.0. Then, using variant 2 down to where you get the position of the Sun, you just need to add: from astropy.coordinates import HADec Then: hadec = sun.transform_to(HADec(obstime=obs_time, location=location)) ha = hadec.ha dec = hadec.dec Regards, Michael Brewer On Tue, Jan 2, 2024 at 11:24?AM Paolo Sereni via AstroPy wrote: > Hello everyone, > > first a couple of words about myself: I am a hobby astronomer and I'm > presently teaching to future physics school-teachers. In my lesson I would > like to introduce some very basics concepts of astronomy and I use > Stellarium as additional tool. My goal is to develop enough material to be > able to understand and build a sun dial. Since I'm also giving an > introductory course in python programming, astropy seems to be the perfect > library to perform some calculations. > > Specifically, I would like to be able to calculate for any given day an > time the *Hour Angle* and Declination of the Sun as seen from Salzburg, > where I live and teach. > > Looking at the impressive documentation of astropy I found two very > promising examples, however both of them calculate RA (right ascension) and > DEC instead of HA (Hour Angle) and DEC. I do not know how to solve this > problem. > > I do not know whether I have to use another "frame" (?) or if I have to > "manually" correct using the Hour Angle of the first point of Aries > (something like HA = HA_Aries + RA)...???? ( in this case where/how can I > find HA_Aries?) > > Here the code of the two examples: > ------------------------------------------- > #Variant 1 > import astropy.units as u > from astropy.coordinates import AltAz, EarthLocation, SkyCoord > from astropy.time import Time > from astropy import coordinates > > Salzburg = EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, > height=424*u.m) > #Salzburg time is UTC +1 we need to correct is > my_time = "2023-12-30T12:00:00" > my_t = Time(my_time) > sun_coordinates = coordinates.get_sun(my_t) > print(type(sun_coordinates)) > print(sun_coordinates) > print("\n\nCoordinates of the sun:") > print("\tright ascension: " + str(sun_coordinates.ra)) > print("\tdeclination: " + str(sun_coordinates.dec)) > print("\tdistance: " + str(sun_coordinates.distance)) > > --------------------------------------------------- > #Variant 2 > from astropy.coordinates import EarthLocation, Longitude, SkyCoord, > get_body, solar_system_ephemeris > from astropy.time import Time > import astropy.units as u > > obs_time = Time('2023-12-30T12:00:00', format='isot', scale='utc') > location=EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m) > solar_system_ephemeris.set('de432s') > sun = get_body('sun', obs_time, location) > print("sun: " + str(sun)) > print("\n\n") > aries = SkyCoord(0*u.deg, 0*u.deg, frame='geocentrictrueecliptic', > obstime=obs_time, equinox=obs_time) > RA = Longitude(sun.itrs.spherical.lon - aries.itrs.spherical.lon) > print("RA =" + str(RA)) > dec = sun.itrs.spherical.lat > print("DEC = " + str(dec)) > > ------- > > Which variant would you recommend me? Any help for obtaining HA will be > greatly appreciated. > > Thank you very much and happy 2024! > > Cheers, Paolo Sereni > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fastropy&data=05%7C02%7Cbrewer%40astro.umass.edu%7C66641c755ccf4e0d62ba08dc0baf4302%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C638398094571940549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MQ9RLZT%2BNaOpE4z91abX%2FS%2Ba8W%2FAFJux8H97I1KWqx0%3D&reserved=0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ejensen1 at swarthmore.edu Tue Jan 2 12:56:31 2024 From: ejensen1 at swarthmore.edu (Eric LN Jensen) Date: Tue, 2 Jan 2024 12:56:31 -0500 Subject: [AstroPy] Question on the coordinates of the sun: Hour angle instead of RA, how? In-Reply-To: <887999441.7520975.1704212633605@mail.yahoo.com> References: <887999441.7520975.1704212633605.ref@mail.yahoo.com> <887999441.7520975.1704212633605@mail.yahoo.com> Message-ID: <8D75CE9E-1032-4D27-A61D-5F74153E03AC@swarthmore.edu> Hi Paolo, Michael has already given a good answer about how to get hour angle directly with astropy routines, but as you?re hoping to teach some of this material, it might also be helpful to point out that it?s straightforward to calculate HA from the RA you?re already getting from the examples you show, plus the related concept of local sidereal time (LST). LST at any given location gives the RA that is currently on the meridian, whereas the hour angle of an object is the amount of time until (or since) the object crosses the meridian. Thus, if you calculate LST from astropy routines (e.g. https://docs.astropy.org/en/stable/api/astropy.time.Time.html#astropy.time.Time.sidereal_time), you can easily find HA from HA_Sun = LST ? RA_Sun Hope this helps, Eric > On Jan 2, 2024, at 11:23 AM, Paolo Sereni via AstroPy wrote: > > Hello everyone, > > first a couple of words about myself: I am a hobby astronomer and I'm presently teaching to future physics school-teachers. In my lesson I would like to introduce some very basics concepts of astronomy and I use Stellarium as additional tool. My goal is to develop enough material to be able to understand and build a sun dial. Since I'm also giving an introductory course in python programming, astropy seems to be the perfect library to perform some calculations. > > Specifically, I would like to be able to calculate for any given day an time the *Hour Angle* and Declination of the Sun as seen from Salzburg, where I live and teach. > > Looking at the impressive documentation of astropy I found two very promising examples, however both of them calculate RA (right ascension) and DEC instead of HA (Hour Angle) and DEC. I do not know how to solve this problem. > > I do not know whether I have to use another "frame" (?) or if I have to "manually" correct using the Hour Angle of the first point of Aries (something like HA = HA_Aries + RA)...???? ( in this case where/how can I find HA_Aries?) > > Here the code of the two examples: > ------------------------------------------- > #Variant 1 > import astropy.units as u > from astropy.coordinates import AltAz, EarthLocation, SkyCoord > from astropy.time import Time > from astropy import coordinates > > Salzburg = EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m) > #Salzburg time is UTC +1 we need to correct is > my_time = "2023-12-30T12:00:00" > my_t = Time(my_time) > sun_coordinates = coordinates.get_sun(my_t) > print(type(sun_coordinates)) > print(sun_coordinates) > print("\n\nCoordinates of the sun:") > print("\tright ascension: " + str(sun_coordinates.ra)) > print("\tdeclination: " + str(sun_coordinates.dec)) > print("\tdistance: " + str(sun_coordinates.distance)) > > --------------------------------------------------- > #Variant 2 > from astropy.coordinates import EarthLocation, Longitude, SkyCoord, get_body, solar_system_ephemeris > from astropy.time import Time > import astropy.units as u > > obs_time = Time('2023-12-30T12:00:00', format='isot', scale='utc') > location=EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m) > solar_system_ephemeris.set('de432s') > sun = get_body('sun', obs_time, location) > print("sun: " + str(sun)) > print("\n\n") > aries = SkyCoord(0*u.deg, 0*u.deg, frame='geocentrictrueecliptic', obstime=obs_time, equinox=obs_time) > RA = Longitude(sun.itrs.spherical.lon - aries.itrs.spherical.lon) > print("RA =" + str(RA)) > dec = sun.itrs.spherical.lat > print("DEC = " + str(dec)) > > ------- > > Which variant would you recommend me? Any help for obtaining HA will be greatly appreciated. > > Thank you very much and happy 2024! > > Cheers, Paolo Sereni > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy ???? Eric Jensen (he/him) Professor of Astronomy Walter Kemp Professor of the Natural Sciences Interim Dean of Academic Success Swarthmore College Parrish E108, 610-328-8249 -------------- next part -------------- An HTML attachment was scrubbed... URL: From serenipaolo at yahoo.com Tue Jan 2 12:58:10 2024 From: serenipaolo at yahoo.com (Paolo Sereni) Date: Tue, 2 Jan 2024 17:58:10 +0000 (UTC) Subject: [AstroPy] Question on the coordinates of the sun: Hour angle instead of RA, how? In-Reply-To: <8D75CE9E-1032-4D27-A61D-5F74153E03AC@swarthmore.edu> References: <887999441.7520975.1704212633605.ref@mail.yahoo.com> <887999441.7520975.1704212633605@mail.yahoo.com> <8D75CE9E-1032-4D27-A61D-5F74153E03AC@swarthmore.edu> Message-ID: <1709950890.7603630.1704218290862@mail.yahoo.com> thank you so much Eric. It works perfectly! Paolo? On Tuesday, January 2, 2024 at 06:57:16 PM GMT+1, Eric LN Jensen wrote: Hi Paolo,? Michael has already given a good answer about how to get hour angle directly with astropy routines, but as you?re hoping to teach some of this material, it might also be helpful to point out that it?s straightforward to calculate HA from the RA you?re already getting from the examples you show, plus the related concept of local sidereal time (LST). ? LST at any given location gives the RA that is currently on the meridian, whereas the hour angle of an object is the amount of time until (or since) the object crosses the meridian. ?Thus, if you calculate LST from astropy routines (e.g. https://docs.astropy.org/en/stable/api/astropy.time.Time.html#astropy.time.Time.sidereal_time), you can easily find HA from HA_Sun = LST ? RA_Sun Hope this helps,? Eric On Jan 2, 2024, at 11:23 AM, Paolo Sereni via AstroPy wrote: Hello everyone, first a couple of words about myself: I am a hobby astronomer and I'm presently teaching to future physics school-teachers. In my lesson I would like to introduce some very basics concepts of astronomy and I use Stellarium as additional tool. My goal is to develop enough material to be able to understand and build a sun dial. Since I'm also giving an introductory course in python programming, astropy seems to be the perfect library to perform some calculations. Specifically, I would like to be able to calculate for any given day an time the *Hour Angle* and Declination of the Sun as seen from Salzburg, where I live and teach. Looking at the impressive documentation of astropy I found two very promising examples, however both of them calculate RA (right ascension) and DEC instead of HA (Hour Angle) and DEC. I do not know how to solve this problem. I do not know whether I have to use another "frame" (?) or if I have to "manually" correct using the Hour Angle of the first point of Aries (something like HA = HA_Aries + RA)...???? ( in this case where/how can I find HA_Aries?)??Here the code of the two examples:-------------------------------------------#Variant 1import astropy.units as u from astropy.coordinates import AltAz, EarthLocation, SkyCoordfrom astropy.time import Timefrom astropy import coordinates Salzburg = EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m)#Salzburg time is UTC +1 we need to correct ismy_time = "2023-12-30T12:00:00"my_t = Time(my_time)sun_coordinates = coordinates.get_sun(my_t)print(type(sun_coordinates))print(sun_coordinates)print("\n\nCoordinates of the sun:")print("\tright ascension:? " + str(sun_coordinates.ra))print("\tdeclination:? ? ?" + str(sun_coordinates.dec))print("\tdistance:? ? ? ? ?" + str(sun_coordinates.distance)) ---------------------------------------------------#Variant 2from astropy.coordinates import EarthLocation, Longitude, SkyCoord, get_body, solar_system_ephemerisfrom astropy.time import Timeimport astropy.units as u obs_time = Time('2023-12-30T12:00:00', format='isot', scale='utc')location=EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m)solar_system_ephemeris.set('de432s')sun = get_body('sun', obs_time, location)print("sun: " + str(sun))print("\n\n")aries = SkyCoord(0*u.deg, 0*u.deg, frame='geocentrictrueecliptic', obstime=obs_time, equinox=obs_time)RA = Longitude(sun.itrs.spherical.lon - aries.itrs.spherical.lon)print("RA ="? + str(RA))dec = sun.itrs.spherical.latprint("DEC = " + str(dec)) ------- Which variant would you recommend me? Any help for obtaining HA will be greatly appreciated. Thank you very much and happy 2024! Cheers, Paolo Sereni _______________________________________________ AstroPy mailing list AstroPy at python.org https://mail.python.org/mailman/listinfo/astropy ???? Eric Jensen (he/him) Professor of AstronomyWalter Kemp Professor of the Natural Sciences Interim Dean of Academic Success Swarthmore CollegeParrish E108, 610-328-8249 _______________________________________________ AstroPy mailing list AstroPy at python.org https://mail.python.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From serenipaolo at yahoo.com Tue Jan 2 13:00:46 2024 From: serenipaolo at yahoo.com (Paolo Sereni) Date: Tue, 2 Jan 2024 18:00:46 +0000 (UTC) Subject: [AstroPy] Question on the coordinates of the sun: Hour angle instead of RA, how? In-Reply-To: <8D75CE9E-1032-4D27-A61D-5F74153E03AC@swarthmore.edu> References: <887999441.7520975.1704212633605.ref@mail.yahoo.com> <887999441.7520975.1704212633605@mail.yahoo.com> <8D75CE9E-1032-4D27-A61D-5F74153E03AC@swarthmore.edu> Message-ID: <1472021110.7595087.1704218446751@mail.yahoo.com> Hi Erich, thank you so much. This is the perfect answer. Cheers, Paolo? On Tuesday, January 2, 2024 at 06:57:16 PM GMT+1, Eric LN Jensen wrote: Hi Paolo,? Michael has already given a good answer about how to get hour angle directly with astropy routines, but as you?re hoping to teach some of this material, it might also be helpful to point out that it?s straightforward to calculate HA from the RA you?re already getting from the examples you show, plus the related concept of local sidereal time (LST). ? LST at any given location gives the RA that is currently on the meridian, whereas the hour angle of an object is the amount of time until (or since) the object crosses the meridian. ?Thus, if you calculate LST from astropy routines (e.g. https://docs.astropy.org/en/stable/api/astropy.time.Time.html#astropy.time.Time.sidereal_time), you can easily find HA from HA_Sun = LST ? RA_Sun Hope this helps,? Eric On Jan 2, 2024, at 11:23 AM, Paolo Sereni via AstroPy wrote: Hello everyone, first a couple of words about myself: I am a hobby astronomer and I'm presently teaching to future physics school-teachers. In my lesson I would like to introduce some very basics concepts of astronomy and I use Stellarium as additional tool. My goal is to develop enough material to be able to understand and build a sun dial. Since I'm also giving an introductory course in python programming, astropy seems to be the perfect library to perform some calculations. Specifically, I would like to be able to calculate for any given day an time the *Hour Angle* and Declination of the Sun as seen from Salzburg, where I live and teach. Looking at the impressive documentation of astropy I found two very promising examples, however both of them calculate RA (right ascension) and DEC instead of HA (Hour Angle) and DEC. I do not know how to solve this problem. I do not know whether I have to use another "frame" (?) or if I have to "manually" correct using the Hour Angle of the first point of Aries (something like HA = HA_Aries + RA)...???? ( in this case where/how can I find HA_Aries?)??Here the code of the two examples:-------------------------------------------#Variant 1import astropy.units as u from astropy.coordinates import AltAz, EarthLocation, SkyCoordfrom astropy.time import Timefrom astropy import coordinates Salzburg = EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m)#Salzburg time is UTC +1 we need to correct ismy_time = "2023-12-30T12:00:00"my_t = Time(my_time)sun_coordinates = coordinates.get_sun(my_t)print(type(sun_coordinates))print(sun_coordinates)print("\n\nCoordinates of the sun:")print("\tright ascension:? " + str(sun_coordinates.ra))print("\tdeclination:? ? ?" + str(sun_coordinates.dec))print("\tdistance:? ? ? ? ?" + str(sun_coordinates.distance)) ---------------------------------------------------#Variant 2from astropy.coordinates import EarthLocation, Longitude, SkyCoord, get_body, solar_system_ephemerisfrom astropy.time import Timeimport astropy.units as u obs_time = Time('2023-12-30T12:00:00', format='isot', scale='utc')location=EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m)solar_system_ephemeris.set('de432s')sun = get_body('sun', obs_time, location)print("sun: " + str(sun))print("\n\n")aries = SkyCoord(0*u.deg, 0*u.deg, frame='geocentrictrueecliptic', obstime=obs_time, equinox=obs_time)RA = Longitude(sun.itrs.spherical.lon - aries.itrs.spherical.lon)print("RA ="? + str(RA))dec = sun.itrs.spherical.latprint("DEC = " + str(dec)) ------- Which variant would you recommend me? Any help for obtaining HA will be greatly appreciated. Thank you very much and happy 2024! Cheers, Paolo Sereni _______________________________________________ AstroPy mailing list AstroPy at python.org https://mail.python.org/mailman/listinfo/astropy ???? Eric Jensen (he/him) Professor of AstronomyWalter Kemp Professor of the Natural Sciences Interim Dean of Academic Success Swarthmore CollegeParrish E108, 610-328-8249 _______________________________________________ AstroPy mailing list AstroPy at python.org https://mail.python.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From brewer at astro.umass.edu Tue Jan 2 13:20:15 2024 From: brewer at astro.umass.edu (Michael Brewer) Date: Tue, 2 Jan 2024 13:20:15 -0500 Subject: [AstroPy] Question on the coordinates of the sun: Hour angle instead of RA, how? In-Reply-To: <1472021110.7595087.1704218446751@mail.yahoo.com> References: <887999441.7520975.1704212633605.ref@mail.yahoo.com> <887999441.7520975.1704212633605@mail.yahoo.com> <8D75CE9E-1032-4D27-A61D-5F74153E03AC@swarthmore.edu> <1472021110.7595087.1704218446751@mail.yahoo.com> Message-ID: Paolo, Not quite. The RA/Dec coordinates returned by get_body('sun', obs_time, location) are in the GCRS reference frame. In order to calculate the apparent hour angle, you need to transform these coordinates to be with respect to the true equator and equinox of date. This consists of adding precession and nutation and can be done thusly: from astropy.coordinates import TETE apparent_radec = sun.transform_to(TETE(obstime=obs_time, location=location)) RA_Sun = apparent_radec.ra Regards, Michael Brewer On Tue, Jan 2, 2024 at 1:01?PM Paolo Sereni via AstroPy wrote: > Hi Erich, > > thank you so much. This is the perfect answer. > > Cheers, Paolo > > On Tuesday, January 2, 2024 at 06:57:16 PM GMT+1, Eric LN Jensen < > ejensen1 at swarthmore.edu> wrote: > > > Hi Paolo, > > Michael has already given a good answer about how to get hour angle > directly with astropy routines, but as you?re hoping to teach some of this > material, it might also be helpful to point out that it?s straightforward > to calculate HA from the RA you?re already getting from the examples you > show, plus the related concept of local sidereal time (LST). > > LST at any given location gives the RA that is currently on the meridian, > whereas the hour angle of an object is the amount of time until (or since) > the object crosses the meridian. Thus, if you calculate LST from astropy > routines (e.g. > https://docs.astropy.org/en/stable/api/astropy.time.Time.html#astropy.time.Time.sidereal_time), > you can easily find HA from > > HA_Sun = LST ? RA_Sun > > Hope this helps, > > Eric > > > On Jan 2, 2024, at 11:23 AM, Paolo Sereni via AstroPy > wrote: > > Hello everyone, > > first a couple of words about myself: I am a hobby astronomer and I'm > presently teaching to future physics school-teachers. In my lesson I would > like to introduce some very basics concepts of astronomy and I use > Stellarium as additional tool. My goal is to develop enough material to be > able to understand and build a sun dial. Since I'm also giving an > introductory course in python programming, astropy seems to be the perfect > library to perform some calculations. > > Specifically, I would like to be able to calculate for any given day an > time the *Hour Angle* and Declination of the Sun as seen from Salzburg, > where I live and teach. > > Looking at the impressive documentation of astropy I found two very > promising examples, however both of them calculate RA (right ascension) and > DEC instead of HA (Hour Angle) and DEC. I do not know how to solve this > problem. > > I do not know whether I have to use another "frame" (?) or if I have to > "manually" correct using the Hour Angle of the first point of Aries > (something like HA = HA_Aries + RA)...???? ( in this case where/how can I > find HA_Aries?) > > Here the code of the two examples: > ------------------------------------------- > #Variant 1 > import astropy.units as u > from astropy.coordinates import AltAz, EarthLocation, SkyCoord > from astropy.time import Time > from astropy import coordinates > > Salzburg = EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, > height=424*u.m) > #Salzburg time is UTC +1 we need to correct is > my_time = "2023-12-30T12:00:00" > my_t = Time(my_time) > sun_coordinates = coordinates.get_sun(my_t) > print(type(sun_coordinates)) > print(sun_coordinates) > print("\n\nCoordinates of the sun:") > print("\tright ascension: " + str(sun_coordinates.ra)) > print("\tdeclination: " + str(sun_coordinates.dec)) > print("\tdistance: " + str(sun_coordinates.distance)) > > --------------------------------------------------- > #Variant 2 > from astropy.coordinates import EarthLocation, Longitude, SkyCoord, > get_body, solar_system_ephemeris > from astropy.time import Time > import astropy.units as u > > obs_time = Time('2023-12-30T12:00:00', format='isot', scale='utc') > location=EarthLocation(lat=13.03333*u.deg, lon=47.8*u.deg, height=424*u.m) > solar_system_ephemeris.set('de432s') > sun = get_body('sun', obs_time, location) > print("sun: " + str(sun)) > print("\n\n") > aries = SkyCoord(0*u.deg, 0*u.deg, frame='geocentrictrueecliptic', > obstime=obs_time, equinox=obs_time) > RA = Longitude(sun.itrs.spherical.lon - aries.itrs.spherical.lon) > print("RA =" + str(RA)) > dec = sun.itrs.spherical.lat > print("DEC = " + str(dec)) > > ------- > > Which variant would you recommend me? Any help for obtaining HA will be > greatly appreciated. > > Thank you very much and happy 2024! > > Cheers, Paolo Sereni > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > > > ???? > Eric Jensen (he/him) > Professor of Astronomy > Walter Kemp Professor of the Natural Sciences > Interim Dean of Academic Success > Swarthmore College > Parrish E108, 610-328-8249 > > > > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fastropy&data=05%7C02%7Cbrewer%40astro.umass.edu%7C248f0a9c24274d7ecee708dc0bbccca5%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C638398152719490618%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dT1v4%2BVwHhRFANdZ%2BwYBtiaydGsCZQDRD2pgeOTt1Yw%3D&reserved=0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvo.email at proton.me Wed Jan 24 08:55:53 2024 From: tvo.email at proton.me (Tien) Date: Wed, 24 Jan 2024 13:55:53 +0000 Subject: [AstroPy] Implementing a versatile natural unit system with astropy? Message-ID: <8TkGwr15BjcrrOp25aNa-YWQnodnJVLf1CCfI2uTS8HoLEaemppTgFRUGM9RJaaRS8d-FamtxflayXhA6dfb9wirQUQONfdwpj1ygRgjXS0=@proton.me> Hi all, I work on heliospheric plasmas and have used astropy intensively in both spacecraft data analysis and numerical simulations. The workflow usually involves converting back and forth between measurements with physical dimensions (as motivation for simulation upstream conditions) and numerical results (as discussion for relevance or importance for observations). As such, I've written many iterations of code that help moving between astropy quantities and natural units (for example, background magnetic field = light speed = vacuum permittivity = particle mass = 1). And I'm finally motivated enough to think about a more well-structured extension for astropy with natural units. I think this will be beneficial to simulators in plasma (and really any other field of) physics who also work closely with experimental results (like most helio-/space physicists). And only recently when I started looking into this that I found out astropy.units was adapted from [a package to analyze astrophysical N-body simulation data](https://github.com/pynbody/pynbody) (which in theory is very similar to simulation data in plasma - particle trajectories or hydrodynamics quantities)! So I think my intentions are well-justified. So I want to survey your thoughts on how this extension may be implemented: (1) as an astropy sub-module or (2) as an affiliated package? (1) A straightforward thing to do would be to open a pull request for an astropy.units.natural? module where, for example, natural_length = u.def_units("natural_length", 0.1 * c.si.R_earth, ...)... so on and so forth for other fundamental dimensions (time, mass, charge). Then a user may be able to convert between astropy.units.si (physical measurements) to astropy.units.natural (for simulations) via UnitBase.to_system. However, a module organized like this is particular for some narrow class of simulations. In plasma physics (both experiments and simulations), we often like to convert between ion scale (fluid; for example natural_length = ion inertial length) and electron scale (kinetic), or to meso-driving scales (sub-ion scale) in turbulence, etc, or to global scales (like the size of the Earth or some fractions of an AU). Surely other areas of physics would also have a diverse range of natural units they'd like to work in. So perhaps this could be a larger package (2), which offers such flexibility. Within plasma physics, this would be a great connection between astropy and plasmapy, which already implemented many quantity-aware common functions. So a simulation setup does not need to re-define, say, what a gyroradius is, and instead just calls plasmapy formulary functions. I'd love to hear your thoughts on this. Feel free to offer comments. -- Tien -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgv.home at gmail.com Wed Jan 24 09:39:14 2024 From: jgv.home at gmail.com (J Vickroy) Date: Wed, 24 Jan 2024 14:39:14 +0000 Subject: [AstroPy] Implementing a versatile natural unit system with astropy? In-Reply-To: <8TkGwr15BjcrrOp25aNa-YWQnodnJVLf1CCfI2uTS8HoLEaemppTgFRUGM9RJaaRS8d-FamtxflayXhA6dfb9wirQUQONfdwpj1ygRgjXS0=@proton.me> References: <8TkGwr15BjcrrOp25aNa-YWQnodnJVLf1CCfI2uTS8HoLEaemppTgFRUGM9RJaaRS8d-FamtxflayXhA6dfb9wirQUQONfdwpj1ygRgjXS0=@proton.me> Message-ID: Hello Tien. Have you considered pint? /jv ________________________________ From: AstroPy on behalf of Tien via AstroPy Sent: Wednesday, January 24, 2024 6:55 AM To: astropy at python.org Cc: Tien Subject: [AstroPy] Implementing a versatile natural unit system with astropy? Hi all, I work on heliospheric plasmas and have used astropy intensively in both spacecraft data analysis and numerical simulations. The workflow usually involves converting back and forth between measurements with physical dimensions (as motivation for simulation upstream conditions) and numerical results (as discussion for relevance or importance for observations). As such, I've written many iterations of code that help moving between astropy quantities and natural units (for example, background magnetic field = light speed = vacuum permittivity = particle mass = 1). And I'm finally motivated enough to think about a more well-structured extension for astropy with natural units. I think this will be beneficial to simulators in plasma (and really any other field of) physics who also work closely with experimental results (like most helio-/space physicists). And only recently when I started looking into this that I found out astropy.units was adapted from a package to analyze astrophysical N-body simulation data (which in theory is very similar to simulation data in plasma - particle trajectories or hydrodynamics quantities)! So I think my intentions are well-justified. So I want to survey your thoughts on how this extension may be implemented: (1) as an astropy sub-module or (2) as an affiliated package? (1) A straightforward thing to do would be to open a pull request for an astropy.units.natural? module where, for example, natural_length = u.def_units("natural_length", 0.1 * c.si.R_earth, ...)... so on and so forth for other fundamental dimensions (time, mass, charge). Then a user may be able to convert between astropy.units.si (physical measurements) to astropy.units.natural (for simulations) via UnitBase.to_system. However, a module organized like this is particular for some narrow class of simulations. In plasma physics (both experiments and simulations), we often like to convert between ion scale (fluid; for example natural_length = ion inertial length) and electron scale (kinetic), or to meso-driving scales (sub-ion scale) in turbulence, etc, or to global scales (like the size of the Earth or some fractions of an AU). Surely other areas of physics would also have a diverse range of natural units they'd like to work in. So perhaps this could be a larger package (2), which offers such flexibility. Within plasma physics, this would be a great connection between astropy and plasmapy, which already implemented many quantity-aware common functions. So a simulation setup does not need to re-define, say, what a gyroradius is, and instead just calls plasmapy formulary functions. I'd love to hear your thoughts on this. Feel free to offer comments. -- Tien -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzuhone at gmail.com Wed Jan 24 09:54:14 2024 From: jzuhone at gmail.com (John Zuhone) Date: Wed, 24 Jan 2024 09:54:14 -0500 Subject: [AstroPy] Implementing a versatile natural unit system with astropy? In-Reply-To: References: <8TkGwr15BjcrrOp25aNa-YWQnodnJVLf1CCfI2uTS8HoLEaemppTgFRUGM9RJaaRS8d-FamtxflayXhA6dfb9wirQUQONfdwpj1ygRgjXS0=@proton.me> Message-ID: <8AE733A2-4FDD-4298-847B-100FE7DA8C48@gmail.com> Also, if you're particularly concerned about simulations, unyt has a natural units system (a couple of versions of it, with the ability to define more), and was originally designed for simulations: unyt.readthedocs.io > On Jan 24, 2024, at 9:39?AM, J Vickroy wrote: > > Hello Tien. Have you considered pint ? /jv > From: AstroPy on behalf of Tien via AstroPy > Sent: Wednesday, January 24, 2024 6:55 AM > To: astropy at python.org > Cc: Tien > Subject: [AstroPy] Implementing a versatile natural unit system with astropy? > > Hi all, > > I work on heliospheric plasmas and have used astropy intensively in both spacecraft data analysis and numerical simulations. The workflow usually involves converting back and forth between measurements with physical dimensions (as motivation for simulation upstream conditions) and numerical results (as discussion for relevance or importance for observations). > > As such, I've written many iterations of code that help moving between astropy quantities and natural units (for example, background magnetic field = light speed = vacuum permittivity = particle mass = 1). And I'm finally motivated enough to think about a more well-structured extension for astropy with natural units. I think this will be beneficial to simulators in plasma (and really any other field of) physics who also work closely with experimental results (like most helio-/space physicists). And only recently when I started looking into this that I found out astropy.units was adapted from a package to analyze astrophysical N-body simulation data (which in theory is very similar to simulation data in plasma - particle trajectories or hydrodynamics quantities)! So I think my intentions are well-justified. > > So I want to survey your thoughts on how this extension may be implemented: (1) as an astropy sub-module or (2) as an affiliated package? > > (1) A straightforward thing to do would be to open a pull request for an astropy.units.natural? module where, for example, natural_length = u.def_units("natural_length", 0.1 * c.si.R_earth, ...)... so on and so forth for other fundamental dimensions (time, mass, charge). Then a user may be able to convert between astropy.units.si (physical measurements) to astropy.units.natural (for simulations) via UnitBase.to_system. > > However, a module organized like this is particular for some narrow class of simulations. In plasma physics (both experiments and simulations), we often like to convert between ion scale (fluid; for example natural_length = ion inertial length) and electron scale (kinetic), or to meso-driving scales (sub-ion scale) in turbulence, etc, or to global scales (like the size of the Earth or some fractions of an AU). Surely other areas of physics would also have a diverse range of natural units they'd like to work in. So perhaps this could be a larger package (2), which offers such flexibility. > > Within plasma physics, this would be a great connection between astropy and plasmapy, which already implemented many quantity-aware common functions. So a simulation setup does not need to re-define, say, what a gyroradius is, and instead just calls plasmapy formulary functions. > > I'd love to hear your thoughts on this. Feel free to offer comments. > -- Tien > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvo.email at proton.me Wed Jan 24 13:50:44 2024 From: tvo.email at proton.me (Tien) Date: Wed, 24 Jan 2024 18:50:44 +0000 Subject: [AstroPy] Implementing a versatile natural unit system with astropy? In-Reply-To: References: <8TkGwr15BjcrrOp25aNa-YWQnodnJVLf1CCfI2uTS8HoLEaemppTgFRUGM9RJaaRS8d-FamtxflayXhA6dfb9wirQUQONfdwpj1ygRgjXS0=@proton.me> Message-ID: Hello, Yes, I recall deciding against using pint and pint-xarray for data analysis at some point (can't remember the exact reason why; I think it's due to robustness? But having an attrs["units"] entry for data storage and converting xarray to astropy Quantity for the calculations that need hairy conversions achieved the intended use so I was good with using astropy.units). -- T -------- Original Message -------- On 1/24/24 07:39, J Vickroy wrote: > Hello Tien. Have you considered [pint](https://pint.readthedocs.io/en/0.23/index.html)? /jv > > --------------------------------------------------------------- > > From: AstroPy on behalf of Tien via AstroPy > Sent: Wednesday, January 24, 2024 6:55 AM > To: astropy at python.org > Cc: Tien > Subject: [AstroPy] Implementing a versatile natural unit system with astropy? > > Hi all, > > I work on heliospheric plasmas and have used astropy intensively in both spacecraft data analysis and numerical simulations. The workflow usually involves converting back and forth between measurements with physical dimensions (as motivation for simulation upstream conditions) and numerical results (as discussion for relevance or importance for observations). > > As such, I've written many iterations of code that help moving between astropy quantities and natural units (for example, background magnetic field = light speed = vacuum permittivity = particle mass = 1). And I'm finally motivated enough to think about a more well-structured extension for astropy with natural units. I think this will be beneficial to simulators in plasma (and really any other field of) physics who also work closely with experimental results (like most helio-/space physicists). And only recently when I started looking into this that I found out astropy.units was adapted from [a package to analyze astrophysical N-body simulation data](https://github.com/pynbody/pynbody) (which in theory is very similar to simulation data in plasma - particle trajectories or hydrodynamics quantities)! So I think my intentions are well-justified. > > So I want to survey your thoughts on how this extension may be implemented: (1) as an astropy sub-module or (2) as an affiliated package? > > (1) A straightforward thing to do would be to open a pull request for an astropy.units.natural? module where, for example, natural_length = u.def_units("natural_length", 0.1 * c.si.R_earth, ...)... so on and so forth for other fundamental dimensions (time, mass, charge). Then a user may be able to convert between astropy.units.si (physical measurements) to astropy.units.natural (for simulations) via UnitBase.to_system. > > However, a module organized like this is particular for some narrow class of simulations. In plasma physics (both experiments and simulations), we often like to convert between ion scale (fluid; for example natural_length = ion inertial length) and electron scale (kinetic), or to meso-driving scales (sub-ion scale) in turbulence, etc, or to global scales (like the size of the Earth or some fractions of an AU). Surely other areas of physics would also have a diverse range of natural units they'd like to work in. So perhaps this could be a larger package (2), which offers such flexibility. > > Within plasma physics, this would be a great connection between astropy and plasmapy, which already implemented many quantity-aware common functions. So a simulation setup does not need to re-define, say, what a gyroradius is, and instead just calls plasmapy formulary functions. > > I'd love to hear your thoughts on this. Feel free to offer comments. > -- Tien -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvo.email at proton.me Wed Jan 24 14:17:43 2024 From: tvo.email at proton.me (Tien) Date: Wed, 24 Jan 2024 19:17:43 +0000 Subject: [AstroPy] Implementing a versatile natural unit system with astropy? In-Reply-To: <8AE733A2-4FDD-4298-847B-100FE7DA8C48@gmail.com> References: <8TkGwr15BjcrrOp25aNa-YWQnodnJVLf1CCfI2uTS8HoLEaemppTgFRUGM9RJaaRS8d-FamtxflayXhA6dfb9wirQUQONfdwpj1ygRgjXS0=@proton.me> <8AE733A2-4FDD-4298-847B-100FE7DA8C48@gmail.com> Message-ID: <2Z_tEIjbicRM5Czz4fj_yx_-_DjNkUl1eM1oFXmf-vacv0Pf6CljKue9Y2JE1MBBKuz7g09vomKU7TF159jKjIMHnZfYe7nOLozWP1sm-JM=@proton.me> Hi John, I wasn't aware of this package. It certainly does almost everything I want to do, and can convert between astropy.units and its own data type (although it looks a bit clunky? Say if I want to use plasmapy functions for calculating quantities, I'll have to do unyt -> astropy.units -> input into plasmapy -> convert back into unyt). From a user perspective, if I only care about doing simulations, then unyt seems like a good library. But then if I want to use astropy and its other utilities, I'll have to manually handle (kind of redundant) conversions between unyt types and astropy types. Wouldn't it still be good to have native support in astropy? Additionally, here's a thought as I type this: in space physics, spacecraft data are often explored interactively (which is why manually handling units and conversions are tedious). But in a simulation library, data are explored more procedurally since they are often saved in local storage (so unit conversions can be handled via whatever library or manually - they are all a few lines of code away). What I want is to make both processes more interactive and the transition between the two more seamless. P/s: I don't particularly like the "unyt" name, but I will consider more of this library. -- T -------- Original Message -------- On 1/24/24 07:54, John Zuhone wrote: > Also, if you're particularly concerned about simulations, unyt has a natural units system (a couple of versions of it, with the ability to define more), and was originally designed for simulations: > > unyt.readthedocs.io > >> On Jan 24, 2024, at 9:39?AM, J Vickroy wrote: >> >> Hello Tien. Have you considered[pint](https://pint.readthedocs.io/en/0.23/index.html)? /jv >> >> --------------------------------------------------------------- >> >> From:AstroPy on behalf of Tien via AstroPy >> Sent:Wednesday, January 24, 2024 6:55 AM >> To:astropy at python.org >> Cc:Tien >> Subject:[AstroPy] Implementing a versatile natural unit system with astropy? >> >> Hi all, >> >> I work on heliospheric plasmas and have used astropy intensively in both spacecraft data analysis and numerical simulations. The workflow usually involves converting back and forth between measurements with physical dimensions (as motivation for simulation upstream conditions) and numerical results (as discussion for relevance or importance for observations). >> >> As such, I've written many iterations of code that help moving between astropy quantities and natural units (for example, background magnetic field = light speed = vacuum permittivity = particle mass = 1). And I'm finally motivated enough to think about a more well-structured extension for astropy with natural units. I think this will be beneficial to simulators in plasma (and really any other field of) physics who also work closely with experimental results (like most helio-/space physicists). And only recently when I started looking into this that I found out astropy.units was adapted from[a package to analyze astrophysical N-body simulation data](https://github.com/pynbody/pynbody)(which in theory is very similar to simulation data in plasma - particle trajectories or hydrodynamics quantities)! So I think my intentions are well-justified. >> >> So I want to survey your thoughts on how this extension may be implemented: (1) as an astropy sub-module or (2) as an affiliated package? >> >> (1) A straightforward thing to do would be to open a pull request for anastropy.units.natural?module where, for example, natural_length = u.def_units("natural_length", 0.1 * c.si.R_earth, ...)... so on and so forth for other fundamental dimensions (time, mass, charge). Then a user may be able to convert between astropy.units.si (physical measurements) to astropy.units.natural (for simulations) via UnitBase.to_system. >> >> However, a module organized like this is particular for some narrow class of simulations. In plasma physics (both experiments and simulations), we often like to convert between ion scale (fluid; for example natural_length = ion inertial length) and electron scale (kinetic), or to meso-driving scales (sub-ion scale) in turbulence, etc, or to global scales (like the size of the Earth or some fractions of an AU). Surely other areas of physics would also have a diverse range of natural units they'd like to work in. So perhaps this could be a larger package (2), which offers such flexibility. >> >> Within plasma physics, this would be a great connection between astropy and plasmapy, which already implemented many quantity-aware common functions. So a simulation setup does not need to re-define, say, what a gyroradius is, and instead just calls plasmapy formulary functions. >> >> I'd love to hear your thoughts on this. Feel free to offer comments. >> -- Tien >> _______________________________________________ >> AstroPy mailing list >> AstroPy at python.org >> https://mail.python.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jzuhone at gmail.com Wed Jan 24 14:37:46 2024 From: jzuhone at gmail.com (John ZuHone) Date: Wed, 24 Jan 2024 14:37:46 -0500 Subject: [AstroPy] Implementing a versatile natural unit system with astropy? In-Reply-To: <2Z_tEIjbicRM5Czz4fj_yx_-_DjNkUl1eM1oFXmf-vacv0Pf6CljKue9Y2JE1MBBKuz7g09vomKU7TF159jKjIMHnZfYe7nOLozWP1sm-JM=@proton.me> References: <2Z_tEIjbicRM5Czz4fj_yx_-_DjNkUl1eM1oFXmf-vacv0Pf6CljKue9Y2JE1MBBKuz7g09vomKU7TF159jKjIMHnZfYe7nOLozWP1sm-JM=@proton.me> Message-ID: <1E5EC635-91AD-4FA2-8A02-F3605BF2C776@gmail.com> > On Jan 24, 2024, at 2:19?PM, Tien via AstroPy wrote: > > From a user perspective, if I only care about doing simulations, then unyt seems like a good library. But then if I want to use astropy and its other utilities, I'll have to manually handle (kind of redundant) conversions between unyt types and astropy types. Wouldn't it still be good to have native support in astropy? Yep, I agree that it would be a nice thing to have. I use both unyt and astropy.units in my work, usually in different contexts (and also where the former isn?t guaranteed to be installed), but they are both excellent implementations. If there?s any way I could help with an astropy implementation I?d be happy to. The main reason the connecting tissue between the two is somewhat kludgey is simply because they use different machinery under the hood?unyt uses sympy to handle all of its symbolic unit operations whereas astropy has rolled its own implementation, so we wouldn?t be able to marry them trivially. From namurphy at cfa.harvard.edu Wed Jan 24 17:51:06 2024 From: namurphy at cfa.harvard.edu (Nick Murphy) Date: Wed, 24 Jan 2024 17:51:06 -0500 Subject: [AstroPy] Implementing a versatile natural unit system with astropy? In-Reply-To: <1E5EC635-91AD-4FA2-8A02-F3605BF2C776@gmail.com> References: <2Z_tEIjbicRM5Czz4fj_yx_-_DjNkUl1eM1oFXmf-vacv0Pf6CljKue9Y2JE1MBBKuz7g09vomKU7TF159jKjIMHnZfYe7nOLozWP1sm-JM=@proton.me> <1E5EC635-91AD-4FA2-8A02-F3605BF2C776@gmail.com> Message-ID: Thank you for bringing this up, and also the very insightful responses! Over in PlasmaPy, I've started to work on classes for representing normalizations of different systems of equations, building on astropy.units. The idea is to create normalization objects which contain attributes with the normalizations for length, time, and other physical types. My goal is to enable operations like: dimensionless_object = dimensional_object / normalizations_object dimensional_object = dimensionless_object * normalizations_object where dimensionless_object and dimensional_object could be single or compound Quantity objects. One of the main purposes would be to facilitate comparisons between simulations and physical systems. I've been meaning to get back to an old pull request to add an MHDNormalizations prototype as a first step, based on the normalizations for the MHD equations. The idea is to provide MHDNormalizations with three quantities representing different types (e.g., length, magnetic field, & number density), and then (for example) get the normalization for time from the time attribute. This is still a work in progress, so I'd be happy to talk more about this and learn more from you about your perspective. Thank you again! On Wed, Jan 24, 2024 at 2:38?PM John ZuHone wrote: > > > > On Jan 24, 2024, at 2:19?PM, Tien via AstroPy > wrote: > > > > From a user perspective, if I only care about doing simulations, then > unyt seems like a good library. But then if I want to use astropy and its > other utilities, I'll have to manually handle (kind of redundant) > conversions between unyt types and astropy types. Wouldn't it still be good > to have native support in astropy? > > Yep, I agree that it would be a nice thing to have. I use both unyt and > astropy.units in my work, usually in different contexts (and also where the > former isn?t guaranteed to be installed), but they are both excellent > implementations. If there?s any way I could help with an astropy > implementation I?d be happy to. > > The main reason the connecting tissue between the two is somewhat kludgey > is simply because they use different machinery under the hood?unyt uses > sympy to handle all of its symbolic unit operations whereas astropy has > rolled its own implementation, so we wouldn?t be able to marry them > trivially. > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvo.email at proton.me Wed Jan 24 19:17:40 2024 From: tvo.email at proton.me (Tien) Date: Thu, 25 Jan 2024 00:17:40 +0000 Subject: [AstroPy] Implementing a versatile natural unit system with astropy? In-Reply-To: References: <2Z_tEIjbicRM5Czz4fj_yx_-_DjNkUl1eM1oFXmf-vacv0Pf6CljKue9Y2JE1MBBKuz7g09vomKU7TF159jKjIMHnZfYe7nOLozWP1sm-JM=@proton.me> <1E5EC635-91AD-4FA2-8A02-F3605BF2C776@gmail.com> Message-ID: Hi Nick, I was hoping for you to chime in, since I've thought of submitting this as a feature request on plasmapy. But I haven't been keeping up with plasmapy updates due to a few recent side quests and am not sure how the simulation module wants to progress over there. What you said was one of my personal code iterations too - to use objects like [conversion factors in this documentation](https://github.com/lanl/vpic/blob/master/doc/vpicUnits.pdf) for the Vector PIC code. I went as far as writing a Quantity subclass (SimQuantity?) with normalization attributes and methods likeSimQuantity.code_to_user?? (returning a dimensional quantity?) and SimQuantity.user_to_code?? (returning a dimensionless quantity?). But I realized this level of abstraction may not be necessary when we can define the conversion factors with astropy.units.def_unit? like L_factor = u.def_unit("L_factor", 10 * u.km)?? T_factor = u.def_unit("T_factor", 0.5 * u.ns)?? Q_factor = u.def_unit("Q_factor", c.si.e)?? M_factor = u.def_unit("M_factor", c.si.m_p)? ... and populate these factors with a method like astropy.units.natural.set_system(system)?? where system?? is one of those in Section 3 of the linked document, which does u.add_enabled_units([L_factor, T_factor, Q_factor, M_factor])?? ... so that they are searchable via UnitBase.find_equivalent_units()??. Now, everyone (data scientists and simulators) can all just use u.Quantity?? for their own purposes. For example, Data scientist: >>> obs_data = load_obs_data()? # magnetic field, electric field, ion cyclotron frequency, etc >>> q = some_data_science_calculations(?obs_data)? ... then, to know what q? is in ion scales>>> u.natural.set_system("ion_scale", ...)? # inject parts of obs_data? here>>> q.to("L_factor")? Simulators: >>> u.natural.set_system("ion_scale", ...)? # inject motivating obs_data?? here >>> p = 0.5 * u.natural.L_factor? >>> q = run_simulation(p)? >>> q.to("km")??? # to see what q? is in si? In these examples, no one has to worry about keeping track of conversion factors themselves, while working on their units of choice and only having intuitive objects storing the dimensional data. And we don't have to subclass astropy.units.Quantity?? at all. I suppose plasmapy? could host such a module like astropy.units.natural?? (i.e., plasmapy.natural_units?; note that it doesn't have to be under plasmapy.simulation??)?. But this will result in loss of generality, because all of the above are not specific to plasma physics. -- T On Wednesday, January 24th, 2024 at 10:51 PM, Nick Murphy via AstroPy wrote: > Thank you for bringing this up, and also the very insightful responses! > > Over in PlasmaPy, I've started to work on classes for representing normalizations of different systems of equations, building on astropy.units. The idea is to create normalization objects which contain attributes with the normalizations for length, time, and other physical types. My goal is to enable operations like: > > dimensionless_object = dimensional_object / normalizations_object > dimensional_object = dimensionless_object * normalizations_object > > where dimensionless_object and dimensional_object could be single or compound Quantity objects. One of the main purposes would be to facilitate comparisons between simulations and physical systems. > > I've been meaning to get back to an old [pull request to add an MHDNormalizations prototype](https://github.com/PlasmaPy/PlasmaPy/pull/1029) as a first step, based on the normalizations for the MHD equations. The idea is to provide MHDNormalizations with three quantities representing different types (e.g., length, magnetic field, & number density), and then (for example) get the normalization for time from the time attribute. This is still a work in progress, so I'd be happy to talk more about this and learn more from you about your perspective. > > Thank you again! > > On Wed, Jan 24, 2024 at 2:38?PM John ZuHone wrote: > >>> On Jan 24, 2024, at 2:19?PM, Tien via AstroPy wrote: >>> >>> From a user perspective, if I only care about doing simulations, then unyt seems like a good library. But then if I want to use astropy and its other utilities, I'll have to manually handle (kind of redundant) conversions between unyt types and astropy types. Wouldn't it still be good to have native support in astropy? >> >> Yep, I agree that it would be a nice thing to have. I use both unyt and astropy.units in my work, usually in different contexts (and also where the former isn?t guaranteed to be installed), but they are both excellent implementations. If there?s any way I could help with an astropy implementation I?d be happy to. >> >> The main reason the connecting tissue between the two is somewhat kludgey is simply because they use different machinery under the hood?unyt uses sympy to handle all of its symbolic unit operations whereas astropy has rolled its own implementation, so we wouldn?t be able to marry them trivially. >> _______________________________________________ >> AstroPy mailing list >> AstroPy at python.org >> https://mail.python.org/mailman/listinfo/astropy -------------- next part -------------- An HTML attachment was scrubbed... URL: