[yt-users] creating sunrise files from RAMSES snapshot
Robert Feldmann
feldmann at fnal.gov
Sun Aug 21 17:23:26 PDT 2011
Hi Matt,
Thanks for looking into it. Yet, the 2.2dev version still fails.
First, there is an issue when I load the RAMSES snapshot.
>>> pf=load("output_00105/info_00105.txt")
output_00105/amr_00105.out00001
yt : [INFO ] 2011-08-21 19:15:20,777 Parameters: current_time = -1.23236270587e+17
yt : [INFO ] 2011-08-21 19:15:20,777 Parameters: domain_dimensions = [2 2 2]
yt : [INFO ] 2011-08-21 19:15:20,778 Parameters: domain_left_edge = [ 0. 0. 0.]
yt : [INFO ] 2011-08-21 19:15:20,778 Parameters: domain_right_edge = [ 1. 1. 1.]
yt : [ERROR ] 2011-08-21 19:15:20,778 Missing cosmological_simulation in parameter file definition!
Yet, despite this error message it does seem to read the RAMSES snapshot. These are the available fields
pf.__class__ pf.__repr__ pf._setup_nounits_units pf.has_key
pf.__delattr__ pf.__setattr__ pf.basename pf.hierarchy
pf.__dict__ pf.__sizeof__ pf.conversion_factors pf.keys
pf.__doc__ pf.__str__ pf.current_time pf.parameter_filename
pf.__format__ pf.__subclasshook__ pf.data_style pf.parameters
pf.__getattribute__ pf.__weakref__ pf.dimensionality pf.print_key_parameters
pf.__getitem__ pf._fieldinfo_class pf.directory pf.ramses_tree
pf.__hash__ pf._handle pf.domain_dimensions pf.refine_by
pf.__init__ pf._hash pf.domain_left_edge pf.storage_filename
pf.__iter__ pf._hierarchy_class pf.domain_right_edge pf.time_units
pf.__metaclass__ pf._instantiated pf.field_info pf.unique_identifier
pf.__module__ pf._instantiated_hierarchy pf.file_style pf.units
pf.__new__ pf._is_valid pf.fullpath
pf.__reduce__ pf._parse_parameter_file pf.get_smallest_appropriate_unit
pf.__reduce_ex__ pf._set_units pf.h
Then when I try to export it, I still get an error.
>>> from yt.analysis_modules.sunrise_export import sunrise_exporter
>>> sunrise_exporter.export_to_sunrise(pf,"analysis/yt/HYDRO_L2_18_GF_epsstar0d1")
yt : [INFO ] 2011-08-21 19:16:38,412 Re-gridding level 0: 1 octree grids
Re-gridding 100% |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:00
...
yt : [INFO ] 2011-08-21 19:16:44,489 Final grid count: 303
yt : [INFO ] 2011-08-21 19:16:44,534 Re-gridding level 16: 59069 octree grids
Re-gridding 100% |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Time: 00:00:00
472552
yt : [INFO ] 2011-08-21 19:16:44,680 Final grid count: 153
int32
yt : [INFO ] 2011-08-21 19:16:45,227 Getting field particle_type from 3250
yt : [INFO ] 2011-08-21 19:16:45,433 Getting field particle_position_x from 3250
yt : [INFO ] 2011-08-21 19:16:45,647 Getting field particle_position_y from 3250
yt : [INFO ] 2011-08-21 19:16:45,858 Getting field particle_position_z from 3250
yt : [INFO ] 2011-08-21 19:16:46,085 Getting field particle_velocity_x from 3250
yt : [INFO ] 2011-08-21 19:16:46,304 Getting field particle_velocity_y from 3250
yt : [INFO ] 2011-08-21 19:16:46,523 Getting field particle_velocity_z from 3250
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (1340, 0))
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (54, 0))
---------------------------------------------------------------------------
NeedsDataField Traceback (most recent call last)
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/scripts/iyt in <module>()
----> 1
2
3
4
5
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/analysis_modules/sunrise_export/sunrise_exporter.pyc in export_to_sunrise(pf, fn, write_particles, subregion_bounds, particle_mass, particle_pos, particle_age, particle_metal)
110 # Velocity is cm/s, we want it to be kpc/yr
111 vel *= (pf["kpc"]/pf["cm"]) / (365*24*3400.)
--> 112 age = pf["years"] * (pf.current_time - reg["creation_time"][pi])
113 creation_time = reg["creation_time"][pi] * pf["years"]
114
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in __getitem__(self, key)
285 if key not in self.fields:
286 self.fields.append(key)
--> 287 self.get_data(key)
288 return self.data[key]
289
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in get_data(self, fields, in_grids, force_particle_read)
2289 continue
2290 if field not in self.hierarchy.field_list and not in_grids:
-> 2291 if self._generate_field(field):
2292 continue # True means we already assigned it
2293 # There are a lot of 'ands' here, but I think they are all
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in _generate_field(self, field)
2356 except NeedsGridType, ngt_exception:
2357 # We leave this to be implementation-specific
-> 2358 self._generate_field_in_grids(field, ngt_exception.ghost_zones)
2359 return False
2360 else:
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in _generate_field_in_grids(self, field, num_ghost_zones)
2366 def _generate_field_in_grids(self, field, num_ghost_zones=0):
2367 for grid in self._grids:
-> 2368 self.__touch_grid_field(grid, field)
2369
2370 @restore_grid_state
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in save_state(self, grid, field)
72 old_keys = grid.data.keys()
73 grid.field_parameters = self.field_parameters
---> 74 tr = func(self, grid, field)
75 grid.field_parameters = old_params
76 grid.data = dict( [(k, grid.data[k]) for k in old_keys] )
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.pyc in __touch_grid_field(self, grid, field)
2370 @restore_grid_state
2371 def __touch_grid_field(self, grid, field):
-> 2372 grid[field]
2373
2374 def _is_fully_enclosed(self, grid):
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/grid_patch.pyc in __getitem__(self, key)
147 """
148 if not self.data.has_key(key):
--> 149 self.get_data(key)
150 return self.data[key]
151
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/grid_patch.pyc in get_data(self, field)
190 else: raise
191 else:
--> 192 self._generate_field(field)
193 return self.data[field]
194
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/grid_patch.pyc in _generate_field(self, field)
125 # First we check the validator
126 try:
--> 127 self.pf.field_info[field].check_available(self)
128 except NeedsGridType, ngt_exception:
129 # This is only going to be raised if n_gz > 0
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/field_info_container.pyc in check_available(self, data)
277 """
278 for validator in self.validators:
--> 279 validator(data)
280 # If we don't get an exception, we're good to go
281 return True
/d/scratch39/feldmann/local/yt_dev/yt-x86_64/src/yt-hg/yt/data_objects/field_info_container.pyc in __call__(self, data)
375 doesnt_have.append(f)
376 if len(doesnt_have) > 0:
--> 377 raise NeedsDataField(doesnt_have)
378 return True
379
NeedsDataField: (['creation_time'])
Best
-R
On Aug 21, 2011, at 9:24 AM, Matthew Turk wrote:
>> I've fixed the bug you have reported, but in the unstable (2.2-dev)
>> version, which also includes a large number of performance
>> improvements for the RAMSES code. (We hope to have a 2.2 release this
>> week.) There seem to be a few lingering bugs with the RAMSES reader
>> which I am going to work on tomorrow; it seems that something I did
>> recently broke the reader.
>
> Apologies for the rapid self-reply, but I believe I have identified
> and fixed the main issue I was seeing with the RAMSES reader, and as
> of changeset hash 677ae185471f (in the "development" branch) it should
> actually be performing up to specification, and I was able to project
> and slice data successfully. Tomorrow I will dive deeper and ensure
> that the second-tier tests are working up to specification.
>
> RAMSES tests will be added to the automated test runner tomorrow
> morning, to be run on a daily basis, to ensure such a regression does
> not happen again. As always, please let us know if you run into
> problems.
>
> Best,
>
> Matt
--
Robert Feldmann
Theoretical Astrophysics Group
Fermi National Accelerator Laboratory
Mail Stop 209,
Box 500
Batavia, IL 60510,
U.S.A
E-mail: feldmann at fnal.gov
Phone: +1 (630) 840-8433
Fax: +1 (630) 840-8231
More information about the yt-users
mailing list