Skip to content
GitLab
Menu
Projects
Groups
Snippets
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
Open sidebar
TurTLE
TurTLE
Commits
65e89b0a
Commit
65e89b0a
authored
Jan 26, 2016
by
Cristian Lalescu
Browse files
Merge branch 'bugfix/src-linking'
parents
dd8ef14d
05a78a8a
Changes
4
Hide whitespace changes
Inline
Side-by-side
bfps/FluidResize.py
View file @
65e89b0a
...
...
@@ -142,15 +142,15 @@ class FluidResize(_fluid_particle_base):
cmd_line_pars
[
k
]
=
opt
.
m
self
.
pars_from_namespace
(
opt
)
src_file
=
os
.
path
.
join
(
opt
.
src_work_dir
,
os
.
path
.
realpath
(
opt
.
src_work_dir
)
,
opt
.
src_simname
+
'_cvorticity_i{0:0>5x}'
.
format
(
opt
.
src_iteration
))
read_file
=
os
.
path
.
join
(
self
.
work_dir
,
opt
.
src_simname
+
'_cvorticity_i{0:0>5x}'
.
format
(
opt
.
src_iteration
))
if
not
os
.
path
.
exists
(
read_file
):
os
.
symlink
(
src_file
,
read_file
)
self
.
set_host_info
(
bfps
.
host_info
)
self
.
write_par
(
iter0
=
opt
.
src_iteration
)
if
not
os
.
path
.
exists
(
read_file
):
os
.
symlink
(
src_file
,
read_file
)
self
.
run
(
ncpu
=
opt
.
ncpu
)
return
None
bfps/NavierStokes.py
View file @
65e89b0a
...
...
@@ -931,7 +931,7 @@ class NavierStokes(_fluid_particle_base):
'--src-wd'
,
type
=
str
,
dest
=
'src_work_dir'
,
default
=
'
./
'
)
default
=
''
)
parser
.
add_argument
(
'--src-simname'
,
type
=
str
,
...
...
@@ -995,6 +995,8 @@ class NavierStokes(_fluid_particle_base):
self
.
parameters
[
'max_Q_estimate'
]
=
meantrS2
self
.
parameters
[
'max_R_estimate'
]
=
.
4
*
meantrS2
**
1.5
if
len
(
opt
.
src_work_dir
)
==
0
:
opt
.
src_work_dir
=
opt
.
work_dir
self
.
pars_from_namespace
(
opt
)
self
.
fill_up_fluid_code
()
self
.
finalize_code
()
...
...
@@ -1014,7 +1016,7 @@ class NavierStokes(_fluid_particle_base):
if
not
os
.
path
.
exists
(
init_condition_file
):
if
len
(
opt
.
src_simname
)
>
0
:
src_file
=
os
.
path
.
join
(
self
.
work_dir
,
os
.
path
.
realpath
(
opt
.
src_
work_dir
)
,
opt
.
src_simname
+
'_cvorticity_i{0:0>5x}'
.
format
(
opt
.
src_iteration
))
os
.
symlink
(
src_file
,
init_condition_file
)
else
:
...
...
bfps/_base.py
View file @
65e89b0a
...
...
@@ -45,7 +45,7 @@ class _base(object):
'ny'
:
32
,
'nz'
:
32
}
self
.
string_length
=
512
self
.
work_dir
=
work_dir
self
.
work_dir
=
os
.
path
.
realpath
(
work_dir
)
self
.
simname
=
simname
return
None
def
cdef_pars
(
self
):
...
...
documentation/_static/development.rst
View file @
65e89b0a
...
...
@@ -7,23 +7,23 @@ Development
Versioning guidelines
---------------------
Version tracking for `bfps` is done with `git` (see https://git-scm.com/
Version tracking for
:mod:
`bfps` is done with
`
`git`
`
(see https://git-scm.com/
for description).
The branching model described at
http://nvie.com/posts/a-successful-git-branching-model/ should be
adhered to as strictly as possible.
The usable `VERSION` number will be constructed according to semantic
versioning rules (see http://semver.org/), `MAJOR.MINOR.PATCH`.
In principle, if you use `bfps` and you've created children of the
`NavierStokes` class, you should not need to rewrite your code unless
the `MAJOR` version changes.
The usable
`
`VERSION`
`
number will be constructed according to semantic
versioning rules (see http://semver.org/),
`
`MAJOR.MINOR.PATCH`
`
.
In principle, if you use
:mod:
`bfps` and you've created children of the
:class:
`NavierStokes
<bfps.NavierStokes.NavierStokes>
` class, you should not need to rewrite your code unless
the
`
`MAJOR`
`
version changes.
There are 2 main branches, `master` and `develop`.
`setup.py` will call `git` to read in the `VERSION`: it will get the
There are 2 main branches,
`
`master`
`
and
`
`develop`
`
.
`
`setup.py`
`
will call
`
`git`
`
to read in the
`
`VERSION`
`
: it will get the
latest available tag.
If the active branch name contains either of the strings `develop`,
`feature` or `bugfix`, then the full output of `git describe --tags`
If the active branch name contains either of the strings
`
`develop`
`
,
`
`feature`
`
or
`
`bugfix`
`
, then the full output of
`
`git describe --tags`
`
will be used;
otherwise, only the string before the dash (if a dash exists) will be
used.
...
...
@@ -32,25 +32,28 @@ At the moment the following rules seem adequate.
Once I get feedback from someone who actually knows how to handle bigger
projects, these may change.
1. New features are worked on in branches forked from `develop`, with
the branch name of the form `feature/bla`.
Feature branches are merged back into `develop` only after all tests
1. New features are worked on in branches forked from
`
`develop`
`
, with
the branch name of the form
`
`feature/bla`
`
.
Feature branches are merged back into
`
`develop`
`
only after all tests
pass.
2. Whenever the `develop` branch is merged into `master`, the last
commit on the `develop` branch is tagged with `MAJOR.MINOR`.
3. Whenever a bug is discovered in version X.Y, a new branch called `vX.Y`
is forked from the corresponding `master` merge point.
A new bugfix branch is forked from `vX.Y`, the bug is fixed, and then
this bugfix branch is merged into all affected branches (this includes
`vX.Y`).
After merging, the respective merge points are tagged adequately (`vX.Y`
gets the tag X.Y.1).
2. Whenever the ``develop`` branch is merged into ``master``, the last
commit on the ``develop`` branch is tagged with ``MAJOR.MINOR``.
3. Whenever a bug is discovered in version X.Y, a new branch called ``vX.Y``
is forked from the corresponding ``master`` merge point.
A new bugfix branch is forked from ``vX.Y``, the bug is fixed.
The last commit in the bugfix branch is tagged X.Y.1.
This bugfix branch is merged into all affected branches (this includes
``vX.Y``).
After merging, the respective merge points into branches other than
``develop``, ``bugfix`` or ``feature`` are tagged accordingly;
there's no need to tag ``develop`` etc since those contain the git
commit in the version anyway.
4. Whenever a bug is discovered in version X.Y.Z, a bugfix branch is
forked from `vX.Y`, and then rule 3 is adapted accordingly.
forked from
`
`vX.Y`
`
, and then rule 3 is adapted accordingly.
------------
Code testing
------------
Testing for `bfps` is done with `tox`.
Testing for
:mod:
`bfps` is done with
`
`tox`
`
.
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment