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.

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

bugs related to boundarychk, electron energy vars, and scr fixed among others #4

Closed
wants to merge 66 commits into from

Conversation

jumasy
Copy link
Contributor

@jumasy jumasy commented Sep 5, 2017

No description provided.

jumasy added 30 commits July 17, 2017 19:49
… here we have specific things from the ebysus code
…a similar format as in IDL, i.e., assign snapshot number while calling the variable and not when we define the object. We store the variables in the structure and cleans when we read new snapshot. Any other features.
… here we have specific things from the ebysus code
@tiagopereira tiagopereira self-assigned this Sep 11, 2017
@tiagopereira
Copy link
Member

tiagopereira commented Sep 11, 2017

I am unable to merge this as is. It is based on an older version of the repository and there are several conflicts. I will have to go through the changes manually and put in the new parts in the current master.

'get composite variable %s. Note that'
'simple_var available variables are: %s' % (var,repr(self.simple_vars))))

def do_mesh(self, x=None, y=None, z=None, nx=None, ny=None, nz=None,
Copy link
Member

Choose a reason for hiding this comment

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

This function is not generic. It has values hardcoded. It does not belong here!


ctypedef fused FLOAT_t:
Copy link
Member

Choose a reason for hiding this comment

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

This should not be removed. Now cstagger.pyx uses fused types.

-------
None. Results saved in cstagger.zupc, cstagger.zdnc.
'''
def init_stagger(int mz, FLOAT_t dx, FLOAT_t dy, np.ndarray[FLOAT_t, ndim=1] z, np.ndarray[FLOAT_t, ndim=1] zdn, np.ndarray[FLOAT_t, ndim=1] dzup, np.ndarray[FLOAT_t, ndim=1] dzdn):
Copy link
Member

Choose a reason for hiding this comment

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

Again, this is replacing previously updated code with an old version.

@jumasy
Copy link
Contributor Author

jumasy commented Sep 11, 2017 via email

@@ -329,44 +360,196 @@ def _get_simple_var_xy(self, var, order='F', mode='r'):
return np.memmap(filename, dtype=self.dtype, order=order, offset=offset,
mode=mode, shape=(self.nx, self.ny))


def _get_composite_var(self, var):
def boundcut(self, name,var):
Copy link
Member

Choose a reason for hiding this comment

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

This function should only be called when params['boundarychk'] = 1, but right now it is called all the time. Besides, it should not even exist. You are getting these problems because you called init_cstagger with self.nz, but you should have used self.nzb, which includes the additional boundary points.

else: # will call xdn, ydn, or zdn to get r at cell faces
return p / getattr(cstagger, var[1] + 'dn')(self.r)
rdt = self.r.dtype
cs.init_stagger(self.nz, self.dx, self.dy, self.z.astype(rdt), self.zdn.astype(rdt), self.dzidzup.astype(rdt), self.dzidzdn.astype(rdt))
Copy link
Member

Choose a reason for hiding this comment

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

Always call init_cstagger with self.nzb instead of self.nz to avoid boundary problems.

return result
elif (len(var) > 2):
if var in ['ixc', 'iyc', 'izc'] or var in ['exc', 'eyc', 'ezc']:
p = self.variables[var[0:2] +'c'] = self.get_var(var[0:2],self.snap)
Copy link
Member

@tiagopereira tiagopereira Sep 13, 2017

Choose a reason for hiding this comment

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

There must be another way for this. Calling self.get_var from inside self._get_composite_var could result in an infinite loop. Please don't do it.

@tiagopereira
Copy link
Member

Most of this was fixed by 51549f3, minus the conflicts. Closing.

@jumasy
Copy link
Contributor Author

jumasy commented Sep 26, 2017 via email

@tiagopereira
Copy link
Member

Yes. But be careful not to lose any files that are not updated in the master.

@jumasy
Copy link
Contributor Author

jumasy commented Sep 26, 2017 via email

M1kol4j pushed a commit that referenced this pull request Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants