<div dir="ltr">Hi Hsi-Yu,<br><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for going through this!</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 27, 2016 at 7:47 PM, Hsi-Yu Schive <span dir="ltr"><<a href="mailto:hyschive@gmail.com" target="_blank">hyschive@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>Hi all,<br><br>I just finish the GAMER frontend for YT, and below I want to summarize some issues and things that might be confusing in the current skeleton frontend. I appreciate if you could help validate these issues and/or clarify some points in the section "Things to be clarified". Hopefully it will make frontend implementation easier in the future. I'll collect all comments and issue a PR for the revised skeleton. It will be complementary to the recent PR #2130 by Jonah Miller, which provides an extremely helpful example frontend.<br><br><br></span><span><b><font color="#0000ff">Things to be clarified:</font><br></b><font color="#0000ff">============================</font><br>1. Difference between <b>FieldInfoContainer.known_other_fields</b> and <b>GridIndex._detect_output_field</b>:<br> => known_other_fields contains fields that *might* be in an output, and lists their units and aliases. _detect_output_fields finds the fields that are defined in the currently loaded dataset.<br></span></div></blockquote><div><br></div><div>Sounds right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><br></span>2. <b>Dataset.unique_identifier</b>:<div> => ??<span><br><br></span></div></div></blockquote><div><br></div><div>This just needs to be unique; for some codes it's a UUID output at runtime. A combination of hash and ctime might work for your data, or even just a random number.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span>3. Set <b>AMRGridPatch.Parent = None</b> for grids without parents, and <b>AMRGridPatch.Children = []</b> for grids without children<br></span></div></div></blockquote><div><br></div><div>Yes, but creating lots of lists can be slow, so some frontends also make it on-demand if Children is None. Some frontends also allow for multiple parents, so that can be a list.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><br>4. Field array returned by <b>BaseIOHandler._read_fluid_selection</b> should be contiguous along the z instead of x direction. Therefore, for C-like array with the dimension [x][y][z] and for Fortran-like array with the the dimension (z,y,x), a matrix transpose is required (e.g., using np_array.transpose() or np_array.swapaxes(0,2))<br></span></div></div></blockquote><div><br></div><div>Yes, unless you swap your coordinate systems in the indexing scheme, which is also possible. You may try doing this my supplying geometry = ("cartesian", ("z", "y", "x")) and not transposing. It may not work, but I think it should.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><br>5. <b>start_index, stop_index, </b>and <b>ActiveDimension</b>s in the AMRGridPatch objects</span></div><div><span> => ??<br> (1) It looks like stop_index is not used anymore<br></span></div></div></blockquote><div><br></div><div>I think that's correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span></span><span> (2) ActiveDimensions will be set by AMRGridPatch._prepare_grid. So perhaps frontend does not need to set it explicitly anymore</span></div></div></blockquote><div><br></div><div>Also correct, unless you can do it faster.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div> (3) It seems that start_index is also calculated automatically<br></div></span></div></blockquote><div><br></div><div>Yes, but this can be overridden, as I think the boxlib frontends do.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div><br>6. <b>chunk, selector, </b>and <b>_read_chunk_data</b> in io.py.</div><div> => ??</div></span><div><span> Also the following comment about caching is confusing:<br> def _read_chunk_data(self, chunk, fields):<br> # This reads the data from a single chunk, and is only used for caching.<br></span></div></div></blockquote><div><br></div><div>That is confusing; it's designed to be a "read data from this chunk without doing any selection" -- then it can be used for caching data that might be used by multiple different selectors later. For instance, this can speed up ghost zone computation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><br></span><span>7. float type:<br> (1) <b>GridIndex.float_type</b> is the float type for left and right simulation edges and must be float64 now<br> (2) <b>BaseIOHandler._read_fluid_selection</b> should always return float64 now even if the on-disk data are stored in single precision<br></span></div></div></blockquote><div><br></div><div>Yes, that's presently the case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><br>8. Difference between <b>add_output_field </b>and <b>add_field </b>used in FieldInfoContainer.setup_fluid_fields:<br></span></div></div></blockquote><div><br></div><div>One means on-disk, the other is not necessarily on-disk.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><br>9. Dataset._parse_parameter_file: what does the following comment mean "Note that these are all assumed to be in code units; domain_left_edge and domain_right_edge will be updated to be in code units at a later time"<br></span><span> => Perhaps it means that "domain_left_edge and domain_right_edge will be converted to YTArray automatically at a later time"?<br></span></div></div></blockquote><div><br></div><div>Yes, that's what it means.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><br><br></span><span><b><font color="#0000ff">Missing procedure</font><br></b><span style="color:rgb(0,0,255)">============================</span><br>1. Add the new frontend in <b>frontends/api.py</b><br>2. Set <b>GridIndex.max_level</b><br>3. Set <b>Dataset.refine_by</b><br><br><br><font color="#0000ff"><b>Bugin the current skeleton frontend</b></font></span></div><span><div><span style="color:rgb(0,0,255)">============================</span><br>1. data_structures.py: <font color="#000000"><b>self.dataset</b></font> is not set in GridIndex.__init__ when calling self.index_filename = self.dataset.parameter_filename<br>2. data_structures.py: replace self.Parent=[] by <b>self.Parent = None</b><br>3. fields.py: the <b>field_list </b>argument is missing in FieldInfoContainer.__init__. This issue has been fixed in Jonah's PR.<br> def __init__(self, ds, field_list):<br> super(SkeletonFieldInfo, self).__init__(ds, field_list)</div><div><br></div><div><br></div></span><div>Sincerely,</div><div>Hsi-Yu (Justin)</div></div>
<br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div><br></div></div>