Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cell Rotations and Translations #225

Merged
merged 24 commits into from
Dec 6, 2015
Merged

Cell Rotations and Translations #225

Show file tree
Hide file tree
Changes from 18 commits
Commits
Show all changes
24 commits
Select commit Hold shift + click to select a range
3bca812
Fixed bug in plotter module when plotting void regions without a mate…
Nov 21, 2015
bcc800c
Initial implementation of rotation attribute and setter in Cell class
Nov 21, 2015
2544255
Cell now computes 3x3 rotation matrix when rotation angles are specified
Nov 21, 2015
b4db6b6
Cell clone now copies rotation angles if any
Nov 21, 2015
0d834c8
Rotations now working for plotting but not yet track generation
Nov 22, 2015
937bb55
Fixed rotations - now working for full core BEAVRS!!!
Nov 22, 2015
c74105e
Fixed a few bugs in OpenCG compatibility module: OpenMOC geometries w…
Nov 22, 2015
897069f
Began refactoring code to apply rotations to angular directions in ra…
Nov 22, 2015
3095060
Ray tracing code now semi-intact - working for pin cell but not latti…
Nov 22, 2015
7487920
Cleanup of refactored ray tracing code, now working for pin cell and …
Nov 23, 2015
fe0b8de
Rotations now appear to be working during ray tracing!!!
Nov 23, 2015
7359765
Restored pin cell sample input file
Nov 23, 2015
477c58f
Cleaned up application of rotations in Universe::findCell()
Nov 23, 2015
4018686
Restored simple-lattice.py input file
Nov 23, 2015
05d693e
Cleaned up doxygen comments for class methods touched by ray tracing …
Nov 23, 2015
a233bb0
Initial implementation of cell translations with getter / setter rout…
Nov 23, 2015
15a31d9
Added translations to ray tracing
Nov 23, 2015
8a000a3
Added translations to OpenCG compatibility module
Nov 23, 2015
8218237
Fixed doxygen comment returns -> return
Dec 1, 2015
5b06cb3
Clarified comments and code for roll-pitch-yaw rotation convention
Dec 1, 2015
5c93374
Addressed comments by @samuelshaner and @geogunow
Dec 1, 2015
2b31945
Reverted comment in OpenCG compatibility module for lattice indexing …
Dec 1, 2015
64f4dc5
Now store rotation angles in radians per comments by @samuelshaner
Dec 1, 2015
0f34157
Added string units parameter to Cell rotation getters and setters met…
Dec 2, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 26 additions & 10 deletions openmoc/compatible/opencg_compatible.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -374,21 +374,29 @@ def get_opencg_cell(openmoc_cell):
name = openmoc_cell.getName()
opencg_cell = opencg.Cell(cell_id, name)

fill = openmoc_cell.getFill()
if (openmoc_cell.getType == openmoc.MATERIAL):
if (openmoc_cell.getType() == openmoc.MATERIAL):
fill = openmoc_cell.getFillMaterial()
opencg_cell.fill = get_opencg_material(fill)
elif (openmoc_cell.getType() == openmoc.FILL):
fill = openmoc_cell.getFillUniverse()
if isinstance(fill, openmoc.Lattice):
opencg_cell.fill = get_opencg_lattice(fill)
else:
opencg_cell.fill = get_opencg_universe(fill)

if openmoc_cell.isRotated():
rotation = openmoc_cell.getRotation(3)
opencg_cell.rotation = rotation * -1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reason for the -1 here and on line 599?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha, it was a little hack while I was trying to figure things out. I've removed it now as I've straightened out things in the roll-pitch-yaw convention of the rotation matrix below.

if openmoc_cell.isTranslated():
rotation = openmoc_cell.getTranslation(3)
opencg_cell.translation = translation

surfaces = openmoc_cell.getSurfaces()

for surf_id, surface_halfspace in surfaces.items():
halfspace = surface_halfspace._halfspace
surface = surface_halfspace._surface
opencg_cell.addSurface(get_opencg_surface(surface), halfspace)
opencg_cell.add_surface(get_opencg_surface(surface), halfspace)

# Add the OpenMOC Cell to the global collection of all OpenMOC Cells
OPENMOC_CELLS[cell_id] = openmoc_cell
Expand Down Expand Up @@ -587,6 +595,13 @@ def get_openmoc_cell(opencg_cell):
else:
openmoc_cell.setFill(get_openmoc_material(fill))

if opencg_cell.rotation is not None:
rotation = np.asarray(opencg_cell.rotation, dtype=np.float64) * -1
openmoc_cell.setRotation(rotation)
if opencg_cell.translation is not None:
translation = np.asarray(opencg_cell.translation, dtype=np.float64)
openmoc_cell.setTranslation(translation)

surfaces = opencg_cell.surfaces

for surface_id in surfaces:
Expand Down Expand Up @@ -753,8 +768,8 @@ def get_openmoc_lattice(opencg_lattice):
universes = opencg_lattice.universes

# Initialize an empty array for the OpenMOC nested Universes in this Lattice
universe_array = np.ndarray(tuple(np.array(dimension[0:2])), \
dtype=openmoc.Universe)
# The Lattice universe array is stored x-y-z in OpenCG, but z-y-x in OpenMOC
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the master branch of OpenCG, it appears OpenCG stores the Lattice universe array in z-y-x, just like in OpenMOC. For instance, line 1045 of opencg/universe.py indexes the universes array with the z-component first:

return self._universes[lat_z][lat_y][lat_x]

Is OpenCG indeed storing the universes array as x-y-z?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right that it is indexed by z-y-x in both codes (or at least should be). I made this comment to myself while I was debugging since I had convinced myself otherwise at one point. I'll revert back to the original comment now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a related note though, OpenCG's dimension attribute is stored as x-y-z since this (may) make more intuitive sense to the user. Hence the need to reverse this array here when initializing OpenMOC's universes array.

universe_array = np.ndarray(tuple(dimension[::-1]), dtype=openmoc.Universe)

# Create OpenMOC Universes for each unique nested Universe in this Lattice
unique_universes = opencg_lattice.get_unique_universes()
Expand All @@ -763,14 +778,15 @@ def get_openmoc_lattice(opencg_lattice):
unique_universes[universe_id] = get_openmoc_universe(universe)

# Build the nested Universe array
for y in range(dimension[1]):
for x in range(dimension[0]):
universe_id = universes[0][y][x].id
universe_array[x][y] = unique_universes[universe_id]
for z in range(dimension[2]):
for y in range(dimension[1]):
for x in range(dimension[0]):
universe_id = universes[z][y][x].id
universe_array[z][dimension[1]-y-1][x] = unique_universes[universe_id]

openmoc_lattice = openmoc.Lattice(lattice_id, name)
openmoc_lattice.setWidth(width[0], width[1], width[2])
openmoc_lattice.setUniverses([universe_array.tolist()])
openmoc_lattice.setUniverses(universe_array.tolist())
openmoc_lattice.setOffset(offset[0], offset[1], offset[2])

# Add the OpenMOC Lattice to the global collection of all OpenMOC Lattices
Expand Down
8 changes: 4 additions & 4 deletions openmoc/map_to_dict.i
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,19 +29,19 @@
/* Typemap for all methods which return a std::map<int, surface_halfspace>.
* This includes the Cell::getSurfaces() method, which is useful for OpenCG
* compatibility. */
%clear std::map<int, surface_halfspace>;
%typemap(out) std::map<int, surface_halfspace> {
%clear std::map<int, surface_halfspace*>;
%typemap(out) std::map<int, surface_halfspace*> {

$result = PyDict_New();
int size = $1.size();

std::map<int, surface_halfspace>::iterator iter;
std::map<int, surface_halfspace*>::iterator iter;
surface_halfspace* surf;
int surf_id;

for (iter = $1.begin(); iter != $1.end(); ++iter) {
surf_id = iter->first;
surf = &iter->second;
surf = iter->second;
PyObject* value =
SWIG_NewPointerObj(SWIG_as_voidptr(surf),
$descriptor(surface_halfspace*), 0);
Expand Down
17 changes: 17 additions & 0 deletions openmoc/numpy_typemaps.i
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,23 @@
* using NumPy arrays */
%apply (double* IN_ARRAY1, int DIM1) {(double* xs, int num_groups)}

/* The typemap used to match the method signature for the Cell rotation
* angle setter method. This allows users to set the rotation angles
* using NumPy arrays */
%apply (double* IN_ARRAY1, int DIM1) {(double* rotation, int num_axes)}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a good reason for using arrays rather than vectors everywhere? If this was a vector, no typemap would be needed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is indeed the case, then I'm sold. I'm not going to make vectors the standard in this PR, but certainly think it would be nice to start using them in place of arrays in some if not all cases, esp. if it would simplify our swig typemaps.


/* The typemap used to match the method signature for the Cell translation
* setter method. This allows users to set translations using NumPy arrays */
%apply (double* IN_ARRAY1, int DIM1) {(double* translation, int num_axes)}

/* The typemap used to match the method signature for the Cell's
* getter method for rotations used by the OpenCG compatibility module. */
%apply (double* ARGOUT_ARRAY1, int DIM1) {(double* rotations, int num_axes)}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this signature need another attribute for the units?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wondered that too, but it doesn't seem too since it works with my test case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm...maybe swig just ignores all arguments after those included in the signature.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I think. But this is related to the way NumPy typemaps work with SWIG - and that isn't particularly well documented IMHO.


/* The typemap used to match the method signature for the Cell's
* getter method for translations used by the OpenCG compatibility module. */
%apply (double* ARGOUT_ARRAY1, int DIM1) {(double* translations, int num_axes)}

/* The typemap used to match the method signature for the TrackGenerator's
* getter methods for track start and end coordinates for the plotting
* routines in openmoc.plotter */
Expand Down
10 changes: 8 additions & 2 deletions openmoc/plotter.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -284,7 +284,10 @@ def plot_materials(geometry, gridsize=250, xlim=None, ylim=None, zcoord=None):
colors = np.zeros((gridsize, gridsize))

for material_id in np.unique(surface):
index = material_ids.index(material_id)
if material_id != -1:
index = material_ids.index(material_id)
else:
index = -1
indices = np.where(surface == material_id)
colors[indices] = index

Expand Down Expand Up @@ -388,7 +391,10 @@ def plot_cells(geometry, gridsize=250, xlim=None, ylim=None, zcoord=None):
colors = np.zeros((gridsize, gridsize))

for cell_id in np.unique(surface):
index = cell_ids.index(cell_id)
if cell_id != -1:
index = cell_ids.index(cell_id)
else:
index = -1
indices = np.where(surface == cell_id)
colors[indices] = index

Expand Down
Loading