setting boundary indicators

[AntonErmakov]

There is something weird near at lines 1502 -- 1523

You have 4 indicators: 0, 1, 2 and 3. I don't get what indicator 3 and 2 are.

Indicator 0: seems like it is when you are at the boundary, but then it gets overwritten.

Indicator 1: Free boundary (not the flat one), no questions here.

Indicator 2: seems like it is just when x or z is less than zero_tolerance, regardless whether or not it's on the boundary, maybe an "else" statement is missing

Indicator 3: seems like it is on the boundary, but x has to be less than 1.0

[elstargazer]

2 is just the no normal flux boundaries. until last week the test here was
x or y = 0 (i.e. zero tolerance) so the being on the boundary condition is
completely redundant. It's obviously effectively the same.

Indicator 3 was probably made when I was benchmarking the thing and trying
to see if the no normal flux BC worked corrected in axisymmetry. I don't
have the code with me now but I don't think it's used anywhere.

PLEASE don't change anything.

Roger

On Sun, Aug 23, 2015 at 7:15 PM, Anton Ermakov [email protected]
wrote:

There is something weird near at lines 1502 -- 1523

You have 4 indicators: 0, 1, 2 and 3. I don't get what indicator 3 and 2
are.

Indicator 0: seems like it is when you are at the boundary, but then it
gets overwritten.

Indicator 1: Free boundary (not the flat one), no questions here.

Indicator 2: seems like it is just when x or z is less than
zero_tolerance, regardless whether or not it's on the boundary, maybe an
"else" statement is missing

Indicator 3: seems like it is on the boundary, but x has to be less than
1.0

—
Reply to this email directly or view it on GitHub
#7.

[AntonErmakov]

Roger,

If I don't change anything, it will be impossible to connect matlab output and C input.

I am working on making ceres.cc work with 2-layer Ceres outputted from matlab (core/shell interface minimizes gravity anomaly). In order for this to work, I need to introduce a new boundary indicator.

Anton.

[elstargazer]

If you can finish these changes in ceres.cc by Tuesday evening, then go
ahead. Otherwise I ask you to do just work on the supporting code and I'll
integrate them into ceres.cc.

Given the experience last week, I'm tired of spending hours not on coding
and improving the code, but just on merging your edits. I'll start working
on the code again Wednesday, so let's have only one person editing the
ceres.cc file at any given point.

Thanks and good luck,
Roger

On Sun, Aug 23, 2015 at 11:35 PM, Anton Ermakov [email protected]
wrote:

Roger,

If I don't change anything, it will be impossible to connect matlab output
and C input.

I am working on making ceres.cc work with 2-layer Ceres outputted from
matlab (core/shell interface minimizes gravity anomaly). In order for this
to work, I need to introduce a new boundary indicator.

Anton.

—
Reply to this email directly or view it on GitHub
#7 (comment).

[AntonErmakov]

I don't think I can do it by Tuesday evening, I am going to the GRAIL meeting on Tuesday evening until Thursday.

Roger, I think you make it sound more dramatic than it actually is. We spent hours on merging because this the first time we did this. If we keep the repos up to date, and always try to edit the latest version it will be easy to merge.

I will create a test branch of my forked version of repository to play with ceres.cc (to make it work with matlab outputted multilayer ceres) and work on it and supporting matlab code. I don't really know how to implement this yet, because it's not a simple geometric condition. If you don't want to spent hours on merging just let me know when you push you changes and I will pull them and merge with whatever I have at that point and then push it back to you.

Anton.

[elstargazer]

Ok, if you're willing to do the merging if it takes a long time... we can
give it a second chance. By the ways, "We" didn't spend hours on
merging... I did! Just don't want to be playing catch up all the time
instead of actually working on the code.

Roger

On Mon, Aug 24, 2015 at 1:02 PM, Anton Ermakov [email protected]
wrote:

I don't think I can do it by Tuesday evening, I am going to the GRAIL
meeting on Tuesday evening until Thursday.

Roger, I think you make it sound more dramatic than it actually is. We
spent hours on merging because this the first time we did this. If we keep
the repos up to date, and always try to edit the latest version it will be
easy to merge.

I will create a test branch of my forked version of repository to play
with ceres.cc (to make it work with matlab outputted multilayer ceres) and
work on it and supporting matlab code. I don't really know how to implement
this yet, because it's not a simple geometric condition. If you don't want
to spent hours on merging just let me know when you push you changes and I
will pull them and merge with whatever I have at that point and then push
it back to you.

Anton.

—
Reply to this email directly or view it on GitHub
#7 (comment).