-
Notifications
You must be signed in to change notification settings - Fork 81
/
astropy.xml
26 lines (26 loc) · 28.7 KB
/
astropy.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../assets/xml/rss.xsl" media="all"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Universe OpenAstronomy (Posts about Astropy)</title><link>http://openastronomy.org/Universe_OA/</link><description></description><atom:link href="http://openastronomy.org/Universe_OA/categories/astropy.xml" rel="self" type="application/rss+xml"></atom:link><language>en</language><lastBuildDate>Wed, 29 May 2024 01:03:43 GMT</lastBuildDate><generator>Nikola (getnikola.com)</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><item><title>astropy@GSoC Blog Post #6.5 - Week 10, Final Evaluations</title><link>http://openastronomy.org/Universe_OA/posts/2021/08/20210814_2236_suyog7130/</link><dc:creator>Suyog Garg</dc:creator><description><p> You know, 7's my lucky number.</p>
<p>And Happy Independence Day!</p>
<!-- TEASER_END --></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2021/08/20210814_2236_suyog7130/</guid><pubDate>Sat, 14 Aug 2021 21:36:00 GMT</pubDate></item><item><title>astropy@GSoC Blog Post #6, Week 8&9</title><link>http://openastronomy.org/Universe_OA/posts/2021/08/20210809_0848_suyog7130/</link><dc:creator>Suyog Garg</dc:creator><description><b>Heads-up about the Progress of <a href="https://github.com/astropy/astropy/pull/11897">#11897</a></b><div><br></div><div> In summary the situation of the concerned PR a few days back was 4 types of CI test errors, one bug and possibly a need for modification of part of the code copied from pycdsreadme. All these have been taken care of as detailed below, but for the numpy depreciation warnings that keep coming up. I don't think we can do anything about the latter's persistence as of now. I shall comment more about it on GitHub as well. </div><div> <ol style="text-align: left;"> <li> <i>File not found error</i>: Moritz's HW, i.e. using <span style="font-family: courier;">get_pkg_data_filename</span> import, directly took care of this. </li> <li> <i>Error in coord col decimal places</i>: The precision of the coordinate component columns was getting set arbitrarily, which created difference in the output for 32-bit and 62-bit machines, and possibly between different operating systems. This has been corrected by having a fixed number of 12 digits after decimal for <b>RAs,</b> <b>DEs</b> and the latitude/longitude columns of Galactic and Ecliptic coords. This error also relates with the Formats bug. </li> <li> <span style="font-family: courier;"><i>SphericalRepresentation</i></span><i> col error</i>: Now, this was a bit major issue compared to the two above, although the solution was only 2 line changes. When the coords cols were checked for and divided into components, the original SkyCoord col was deleted right within the loop. This made the iteration index of the loop to point to i+2 column after deletion, where i is the index of the original <span style="font-family: courier;">SkyCoord</span> col. That is, effectively skipping the immediate next column after the <span style="font-family: courier;">SkyCoord</span> col, as it would have receded by one place in the list. Got this fixed by popping the original <span style="font-family: courier;">SkyCoord</span> col after all the columns in the table have been iterated over. This way all <span style="font-family: courier;">object</span> type columns are converted to <span style="font-family: courier;">Column</span> objects with <span style="font-family: courier;">str</span> values. </li> <li> <i>~table.tests and </i><span style="font-family: courier;"><i>test_write</i></span><i> failures</i>: All these errors were warnings due to depreciation of numpy specific aliases for different Python types. Most previous tests in Astropy appear to use these now depreciated numpy types, which raises warnings during testing our code. I have been able to provide remedy for majority of these by additionally using <span style="font-family: courier;">np.issubdtype(col.dtype, np.integer)</span> while checking if the columns has integer values, however, tests with oldest supported version of all dependencies still fails. See my GitHub comment for more info. </li> </ol> <i><div><i><br></i></div>The </i><span style="font-family: courier;"><i>formats</i></span><i> bug</i></div><div><i><br></i></div><div> This was another major problem we had stumbled upon. It took me a while to skim through various docs and codes to find the optimum fix for this. </div><div><br></div><div> Our initial insight was that the difference between the Byte-By-Byte description and the data part of the written table, when the <span style="font-family: courier;">formats</span> argument is passed to the <span style="font-family: courier;">write</span> function, related in some manner to the string formatting part of the code. By first look itself, it was evident that there isn't any provision in the writer for cases when the columns already contain a <span style="font-family: courier;">format</span> attribute, which is what is assigned when <span style="font-family: courier;">formats</span> is passed, as I had written here back then. Creating allowance for this was easy enough, right away correcting the test outputs. Now, both the Byte-By-Byte and the table data had the number of decimal digits, or whatever other format for that matter, we wanted them to have. Apart from the internally created coordinate component columns, for which the number of digits after decimal was fixed. </div><div><br></div><div> It is when we want to go a step further than this and wanna truncate or eradicate the string formatting part to obtain the column format, that we stumble upon a road block. There are two concerns, </div><div> <ul style="text-align: left;"> <li> If no <span style="font-family: courier;">formats</span> argument is passed, <span style="font-family: courier;">col.format</span> will be set to <span style="font-family: courier;">None</span>. </li> <li> Even if we already know the column format, say <span style="font-family: courier;">.5f</span>, we still need to evaluate the maximum size of the value strings of the column in most cases, and do some formatting to have the format in CDS/MRT recommendation, <span style="font-family: courier;">Fx.5</span>. </li> </ul> The column <span style="font-family: courier;">formats</span> passed in the formats argument are set by using the in-build Python function <span style="font-family: courier;">format</span> (<a href="https://docs.python.org/3/library/functions.html#format">https://docs.python.org/3/library/functions.html#format</a>). For cases when no formats argument is passed, the default behavior when writing the table data, for instance in the <span style="font-family: courier;">FixedWidth</span> writer is to set the column format to <span style="font-family: courier;">''</span> which is equivalent to saying <span style="font-family: courier;">val = str(val)</span>. (<a href="https://docs.astropy.org/en/stable/table/construct_table.html#table-format-string">https://docs.astropy.org/en/stable/table/construct_table.html#table-format-string</a>) <span style="font-family: courier;">FixedWidth</span> uses the maximum length of these strings to get the column widths. <b>So, there the string formatting part of the code is essential if we want to know the correct format for columns without string values.</b></div><div><br></div><div> However, there may be another solution to this that can be tried in the long-term. I was curious to know what other writers in Astropy did in such situations when the column format needs to be given explicitly in the header of the written table. There aren't extravagantly many such use cases, but the FITS standard tables do have format keywords in the header as serve the purpose well. So, looking over the Astropy FITS writer, I found the way in which it deals with the problem of assigning column formats is by separately defining all the formats that can be and then using a custom <span style="font-family: courier;">Column</span> class which has some default format attributes. (See:<br><a href="https://github.com/astropy/astropy/blob/main/astropy/io/fits/column.py">https://github.com/astropy/astropy/blob/main/astropy/io/fits/column.py</a>). ASCII writers also have a custom <span style="font-family: courier;">Column</span> class, but the attributes that it currently has are exceedingly lacking to be of any use to us now. (<a href="https://github.com/astropy/astropy/blob/79323de928e87827526ed8fce04986a5dd459794/astropy/io/ascii/core.py#L270">https://github.com/astropy/astropy/blob/79323de928e87827526ed8fce04986a5dd459794/astropy/io/ascii/core.py#L270</a>) In the long-run, we could take motivation from the FITS writer and make changes herein.<br><br><i>Other updates</i></div><div> <i><br></i> <div> <div> I have began to work on the other two branches for Time cols and MRT metadata resp and would have them done in some time. </div> <div> On an unrelated note, I found that the <span style="font-family: courier;">test_cds_header_from_readme.py</span> test file in <span style="font-family: courier;"><a href="http://astropy.io/">astropy.io</a>.ascii.tests</span> contains some CDS reading tests. It was recently modified by the 11593 PR (<a href="https://github.com/astropy/astropy/pull/11593/files">https://github.com/astropy/astropy/pull/11593/files</a>). I imagine that these tests can be incorporated within test_cds.py and then we won't perhaps have to move CDS/MRT tests to any other test file? </div> </div></div>
<!-- TEASER_END --></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2021/08/20210809_0848_suyog7130/</guid><pubDate>Mon, 09 Aug 2021 07:48:00 GMT</pubDate></item><item><title>astropy@GSoC Blog Post #5, Week 6&7</title><link>http://openastronomy.org/Universe_OA/posts/2021/07/20210721_2000_suyog7130/</link><dc:creator>Suyog Garg</dc:creator><description><p>Hi,</p>
<p>How are you?</p>
<p>My dear mentors and I have decided to have the MRT (Machine Readable Table) format writing first. The same CDS code as been used now will be used, just the template of the written table will be in the MRT format.</p>
<!-- TEASER_END -->
<p>Points to be noted regarding this and the immediate things that have been and will done are as follows:</p>
<p></p>
<ul style="text-align: left;"><li>Leave out writing all the optional CDS ReadMe fields as of now. These can be dealt with individual PRs later.</li><li>Some tests fail because <span style="font-family: courier;">start_line = None</span> doesn't work. It has been introduced once again within <span style="font-family: courier;">CdsData.write</span> function in addition to been defined in the main <span style="font-family: courier;">Cds</span> class. The test failure occurs because CdsData now inherits from <span style="font-family: courier;">FixedWidthData</span> which itself inherits <span style="font-family: courier;">basic.BasicReader</span> instead of BaseReader. I should make sure that all tests pass properly.</li><li>Have a template for MRT tables and write them first. <b>Title</b>, <b>Authors</b>, <b>Date</b>, <b>Caption</b> and <b>Notes</b> sections, i.e. all sections except the Byte-By-Byte and the Data itself, will be left blank in the template, with warning for the user to put them in manually afterwards.</li><li>Documentation for the CDS/MRT format writer.</li><li>At present issue a warning note for tables with two or more mix-in columns (<span style="font-family: courier;">SkyCoord</span> cols primarily). If ways to correctly work out such situations is thought of, add that feature in a separate PR.</li><li>Work with a copy of the original table, so that the copy is modified and not the original table, when component coordinate columns are written. The modified copy of the table is written to a file, while the user retains access to the columns of the original table.</li><li>Need to have features to recognise non Spherical coordinates, like the Cartesian coordinates, and either skip them or write them as Single column string values. Add test for such other coordinates. Also for cases when coordinates are in a <span style="font-family: courier;">SkyCoord</span> object but the frame is not Spherical.</li><li>Have two other templates, one for CDS in which the user fills values of optional fields manually later and another in which filling optional fields can be done from within Astropy, via a <span style="font-family: courier;">cdsdict</span>. In separate PRs. Here too write only the required fields in the ReadMe first, like <b>Abstract</b>.</li><li>Have features for Time columns later within the original PR or much later.</li><li>Simplify how column format is obtained for float columns. The current manner of string formatting is too complicated. <span style="font-family: courier;">col.width</span> value can be directly used in some cases. The <span style="font-family: courier;">Outputter</span> class will also know the column format since it writes out the table.</li><li>Other minor/major edits and modifications as suggested by others.</li></ul><div>With this PR for the MRT format table writing getting eventually merged to Astropy, the main goal of my astropy@GSoC project will be completed. The support for other extra features essentially serves as appendages to the primary task been done by this PR.</div><div>Let's see how it goes.</div><div><br></div><div>Oh! On another note, a few days back I received the GSoC First Evaluations payment! 😁</div><div><br></div><div>Adious!</div><p></p></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2021/07/20210721_2000_suyog7130/</guid><pubDate>Wed, 21 Jul 2021 19:00:00 GMT</pubDate></item><item><title>astropy@GSoC Blog Post #4, Week 4</title><link>http://openastronomy.org/Universe_OA/posts/2021/07/20210709_2232_suyog7130/</link><dc:creator>Suyog Garg</dc:creator><description><p>Hi,</p>
<p>How you doing?</p>
<p>Yup! Lots of things done again. I have finally completed the main goal of the project. Yahoo!</p>
<!-- TEASER_END --></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2021/07/20210709_2232_suyog7130/</guid><pubDate>Fri, 09 Jul 2021 21:32:00 GMT</pubDate></item><item><title>astropy@GSoC Blog Post #3, Week 3</title><link>http://openastronomy.org/Universe_OA/posts/2021/06/20210623_2223_suyog7130/</link><dc:creator>Suyog Garg</dc:creator><description><p>So, it's the start of the 3rd week now. I will be virtually meeting Aarya and Moritz again Tom.<br><br>For the past few weeks now, I have been pushing commits to a Draft PR <a href="https://github.com/astropy/astropy/pull/11835">https://github.com/astropy/astropy/pull/11835</a> on GitHub. I wanted to have something working quite early in the project, in order to be able to pinpoint accurately when something doesn't work. This is why I started with directly adding the <b>cdspyreadme</b> code within Astropy. Afterwards, I am also writing the code from scratch. As more of the required features from <b>cdspyreadme</b> get integrated into <i>cds.py</i>, those files and codes added earlier will be removed.<br><br>About the reading/writing to Machine Readable Table format, in fact I wrote about it briefly in my GSoC Proposal that I could attempt it as an extension. I don't have an opinion on whether or not it should have it's own format classes etc. However, since the title of my GSoC project is to <b>Add a CDS format writer to Astropy</b>, I would prefer to work on the CDS format writer first and then on the MRT format. The MRT header anyway appears to be a bit simpler than the CDS header, so there shouldn't be much difficulty in the extension.<br><br>So, in a nutshell, this is my workflow:<br></p><ul style="text-align: left;"><li>Try out directly using <b>cdspyreadme</b> from within Astropy.</li><li>Add CdsData.write method.</li><li>Add a ByteByByte writer.</li><li>Write features to add complete ReadMe to the Header, starting off with having both ReadMe and Data in a single file.</li><li>Have features for writing separate CDS ReadMe and Data file.</li><li>Further work on some specific table columns, for instance, those containing Units and Coordinates.</li><li>Add appropriate tests along the way.</li><li>Resolve other issues that come up.</li><li>MRT format reader/writer.</li></ul><br>I have completed the first three tasks and will now work on the fourth. I think by the time this finishes, a separate <i>CDSColumn.py</i> won't be required. I can open another PR which adds the Data writer, in the meantime.<div><br></div><div>Let's see how it goes!</div>
<!-- TEASER_END --></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2021/06/20210623_2223_suyog7130/</guid><pubDate>Wed, 23 Jun 2021 21:23:00 GMT</pubDate></item><item><title>astropy@GSoC Blog Post #3, Week 3</title><link>http://openastronomy.org/Universe_OA/posts/2021/06/20210622_2223_suyog7130/</link><dc:creator>Suyog Garg</dc:creator><description><p>So, it's the start of the 3rd week now. I will be virtually meeting Aarya and Moritz again Tom.<br><br>For the past few weeks now, I have been pushing commits to a Draft PR <a href="https://github.com/astropy/astropy/pull/11835">https://github.com/astropy/astropy/pull/11835</a> on GitHub. I wanted to have something working quite early in the project, in order to be able to pinpoint accurately when something doesn't work. This is why I started with directly adding the <b>cdspyreadme</b> code within Astropy. Afterwards, I am also writing the code from scratch. As more of the required features from <b>cdspyreadme</b> get integrated into <i>cds.py</i>, those files and codes added earlier will be removed.<br><br>About the reading/writing to Machine Readable Table format, in fact I wrote about it briefly in my GSoC Proposal that I could attempt it as an extension. I don't have an opinion on whether or not it should have it's own format classes etc. However, since the title of my GSoC project is to <b>Add a CDS format writer to Astropy</b>, I would prefer to work on the CDS format writer first and then on the MRT format. The MRT header anyway appears to be a bit simpler than the CDS header, so there shouldn't be much difficulty in the extension.<br><br>So, in a nutshell, this is my workflow:<br></p><ul style="text-align: left;"><li>Try out directly using <b>cdspyreadme</b> from within Astropy.</li><li>Add CdsData.write method.</li><li>Add a ByteByByte writer.</li><li>Write features to add complete ReadMe to the Header, starting off with having both ReadMe and Data in a single file.</li><li>Have features for writing separate CDS ReadMe and Data file.</li><li>Further work on some specific table columns, for instance, those containing Units and Coordinates.</li><li>Add appropriate tests along the way.</li><li>Resolve other issues that come up.</li><li>MRT format reader/writer.</li></ul><br>I have completed the first three tasks and will now work on the fourth. I think by the time this finishes, a separate <i>CDSColumn.py</i> won't be required. I can open another PR which adds the Data writer, in the meantime.<div><br></div><div>Let's see how it goes!</div>
<!-- TEASER_END --></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2021/06/20210622_2223_suyog7130/</guid><pubDate>Tue, 22 Jun 2021 21:23:00 GMT</pubDate></item><item><title>astropy@GSoC Blog Post #2, Week 1&2</title><link>http://openastronomy.org/Universe_OA/posts/2021/06/20210619_2154_suyog7130/</link><dc:creator>Suyog Garg</dc:creator><description><p>Hi,</p>
<p>How are you?</p>
<p>So, it's been two weeks of astropy@GSoC work already. Of course I have been damn busy! With the last commit made to the draft PR <a href="https://github.com/astropy/astropy/pull/11835">https://github.com/astropy/astropy/pull/11835</a>, a few hours back, I have successfully written a basic CDS writer. And voilà it works, albeit without the ReadMe at present! 😁</p>
<!-- TEASER_END -->
<p>Note that I am quite unlikely to go into technical details here in these posts. There are two reasons for this. Hhm..., Na I guess there's just one single reason. It would be too repetitive a task to write them. I already write aplenty about those in the GitHub comments and other communications. And of course, the whole codes I am writing during the project are available publicly on GitHub, for the overly curious kind. Moreover, the final report is gonna have more than ample discussion too, because I like to explain myself a lot. 😐 What then is the need to write all that here again? So consider these posts my plain uncouth thoughts, which in any case, I suppose, aligns more with the spirit OpenAstronomy asks these for.</p>
<p>On a second important point, honestly, these Astropy people are really intelligent. It would appear, even more as the project progresses, that they knowingly marked a normal project as <i>Easy</i> to lure some innocent students! 😂</p>
<p>Anyway, Bye.</p>
<p>See ya the next time! 🙋♂️</p>
<p><br></p>
<p><br></p></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2021/06/20210619_2154_suyog7130/</guid><pubDate>Sat, 19 Jun 2021 20:54:00 GMT</pubDate></item><item><title>astropy@GSoC Blog Post #1</title><link>http://openastronomy.org/Universe_OA/posts/2021/06/20210606_1659_suyog7130/</link><dc:creator>Suyog Garg</dc:creator><description><div>Hey there,</div><div><br></div><div>How are you?</div><div>Chances are that you are coming across me for the first time.</div><div>Nice meeting you too! 😄</div><div><br></div><div> Since this is an introductory astropy@GSoC Blog Post, I would keep things brief.</div><div><br></div><div> <br> <div class="separator" style="clear: both; text-align: center;"> <img alt="" height="336" src="https://lh3.googleusercontent.com/-kVduvrsYzQ4/YL0ClAcy0hI/AAAAAAAA3Yk/PrbBQBkgxu8Y_f7-qpLAPlI6tr0zISXFgCLcBGAsYHQ/w336-h336/image.png" width="336"><div style="margin-left: 1em; margin-right: 1em;"> <div class="separator" style="clear: both; text-align: center;"><a href="https://lh3.googleusercontent.com/-OkQcow92n4s/YL0DELFw56I/AAAAAAAA3Y0/43e2Ak8Bsy8VaTSw6RYB3ryocKQUCnM1ACLcBGAsYHQ/image.png" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img alt="" height="154" src="https://lh3.googleusercontent.com/-OkQcow92n4s/YL0DELFw56I/AAAAAAAA3Y0/43e2Ak8Bsy8VaTSw6RYB3ryocKQUCnM1ACLcBGAsYHQ/image.png" width="320"></a><img alt="" height="169" src="https://lh3.googleusercontent.com/-qshucfTcxpY/YL0CwsGOS2I/AAAAAAAA3Yo/OGuKkhEkZtkmz3xw6qVy3YYTANGN5Zi2gCLcBGAsYHQ/w169-h169/image.png" style="text-align: center;" width="169"></div></div></div></div><div><br></div><div><br></div><div>As you probably already know, my name is Suyog and I am a participant for Google Summer of Code (GSoC) 2021. Over the course of the next 10 weeks or so, I will be working on the Astropy project under the umbrella organisation OpenAstronomy. During this while, I aim to add a CDS format writer to the Astropy library with the help of my affable mentors Aarya and Moritz. </div><div><br></div><div>I had actually also applied for GSoC last summer, however I had failed to pass one of the eligibility criteria, and so wasn't selected. This astropy@GSoC project, therefore, is quite an awesome opportunity for me. I am looking forward to making the most of it and enjoying the time all the same. </div><div><br></div><div>There are two preliminary observations:</div><div> 1. The associated stipend, albeit somewhat lower than what used to be the case a few years back, is freaking awesome. 😉 </div><div> 2. Dunno, why this project is marked as Difficultly Low!? Nothing as easy as being just the third person to write a Table writer for the world's largest Astronomy code library! 😂😎 </div><div><br></div><div>Alright. Bye.</div><div>See ya the next time! 🙋♂️</div><div><br></div><div> Stay tuned for more GSoC updates, or what is far better, for the next post in general. </div>
<!-- TEASER_END --></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2021/06/20210606_1659_suyog7130/</guid><pubDate>Sun, 06 Jun 2021 15:59:00 GMT</pubDate></item><item><title>Final GSoC Post</title><link>http://openastronomy.org/Universe_OA/posts/2019/08/20190825_1632_tcjansen/</link><dc:creator>astrojansen</dc:creator><description><p>Wow, what a journey! It’s hard to believe that GSoC is coming to an end. This project has taken quite a few twists and turns, which I will attempt to lead you through here, but ultimately I think it has all come together into a product that will be useful for anyone in the astronomical … Continue re <a class="reference external" href="https://astrotiff.home.blog/2019/08/25/final-gsoc-post/">...READ MORE...</a></p></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2019/08/20190825_1632_tcjansen/</guid><pubDate>Sun, 25 Aug 2019 15:32:49 GMT</pubDate></item><item><title>Week 13: Hello from Reykjavik!</title><link>http://openastronomy.org/Universe_OA/posts/2019/08/20190820_1923_tcjansen/</link><dc:creator>astrojansen</dc:creator><description><p>What I completed this week: Moved basically all of the stuff I’ve been exploring with synphot over to astroplan, which in hindsight makes more sense! In brief, this is what I did: Added a new module exptime.py to astroplan, which uses synphot to calculate the exposure time needed to obtain a given s <a class="reference external" href="https://astrotiff.home.blog/2019/08/20/week-13-hello-from-reykjavik/">...READ MORE...</a></p></description><category>Astropy</category><guid>http://openastronomy.org/Universe_OA/posts/2019/08/20190820_1923_tcjansen/</guid><pubDate>Tue, 20 Aug 2019 18:23:53 GMT</pubDate></item></channel></rss>