Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Conversion of BCs on loading Block objects should be parameterized. That is, Case should allow a callable property to assign the logic to convert BCs.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/13

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

solvcon.hook.PMarchSave use postloop() to ensure an output at the end of simulation. When cse.execution.step_current % ssteps == 0, the ending output duplicated.

On the other hand solvcon.hook.PVtkHook does not have the ending operation, which should be added.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/28

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Mailing list, IRC channel, etc.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/9

Originally reported by: David Bilyeu (BitBucket: david_b, GitHub: david_b)

The linux kernel site is currently down so the gcc compiler cannot be downloaded at this time.
a quick fix is to change the gcc url to
ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.1/gcc-4.6.1.tar.bz2

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/48

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

SOLVCON has various external dependencies, including Python (2.6/7), SCons (1.2+), numpy, LAPACK, netCDF (4+), metis (4.0.3), scotch (5.1+), VTK (5.6+), MPI2, nosetests (1.0+), epydoc (1.0+). Some of them are prerequisite, while some are optional.

There should be a supplemental system distributed with SOLVCON package to help building these dependencies. It will be very helpful for deploying SOLVCON on older OSes, e.g., RHEL 4, 5, 5.5, which are usually used by supercomputers.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/39

Originally reported by: David Bilyeu (BitBucket: david_b, GitHub: david_b)

Tried to run cuda test case and got this error.
(I compiled this test after commenting out this line
https://bitbucket.org/yungyuc/solvcon/src/f37462b10ca5/sandbox/cuda/SConscript#cl-37
)
This was the python error.

david@cuda-togo:cuda$ ./go run
Traceback (most recent call last):
File "./go", line 29, in
import cueuler
File "/home/david/Programs/dunadan/solvcon/sandbox/cuda/cueuler.py", line 23, in
from solvcon.gendata import AttributeDict
ImportError: No module named solvcon.gend

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/20

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Currently head node load domain connectivity arrays, which is about 150MB per million elements. For 50 million elements the head node needs up to 7.5 GB of memory. This becomes a bottleneck of memory usage.

Loading of domain connectivity arrays on head node should be revised.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/31

Originally reported by: David Bilyeu (BitBucket: david_b, GitHub: david_b)

I would like the ability to specify any of the two of: simulation time, dt or number of steps and then have the third automatically calculated. When I try to modify time_increment or steps_run in the driving script I get errors or werid behavior. I can post the traceback later if you need it.

I would also like to specify a printing time step rather than the number of time steps. This would be helpful when comparing the same simulation with two different meshes. This will also be useful for variable dt.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/30

Originally reported by: Po-Hsien Lin (BitBucket: ericpo, GitHub: ericpo)

Hello YYC,

In gasdynb/bound_wall.c, line 246, you wrote
vmt[it][jt] = mvt[it][0]_vec[1][jt] + mat[it][1]_vec[2][jt]
is it that should change to
vmt[it][jt] = mvt[it][0]_vec[1][jt] + mvt[it][1]_vec[2][jt]

In cuse/calc_dsoln_w3.c, line347~352, you wrote
};
#ifndef CUDACC
return 0;
};
#else
};
should it change to

#ifndef __CUDACC__
};
return 0;

};

else

};

Thank you very much.

eric

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/50

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/2

Originally reported by: David Bilyeu (BitBucket: david_b, GitHub: david_b)

Error when building cuda test.
This is the error message
gcc -o libsc_gasdyn2d_c.so -shared -L/home/david/NVIDIA_GPU_Computing_SDK/C/lib -L/home/david/NVIDIA_GPU_Computing_SDK/C/common/lib/linux -L/usr/local/cuda/lib64 -L/usr/local/cuda/lib
gcc: no input files

scons -v

script: v2.0.0.final.0.r5023, 2010/06/14 22:05:46, by scons on scons-dev

I can comment out

https://bitbucket.org/yungyuc/solvcon/src/f37462b10ca5/sandbox/cuda/SConscript#cl-37

and it will compile.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/19

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

solvcon.rpc.create_solver() calls solvcon.io.domain.DomainIO.load_block() to load corresponding block file. DomainIO.load_block() currently will load the domain.dom file in the domain directory, which results into reading conflict for many sub-domains.

  File "/nfs/04/osu4914/opt/bin/scg", line 23, in <module>
    solvcon.go()
  File "/nfs/04/osu4914/opt/lib/python2.6/site-packages/solvcon/cmdutil.py", line 176, in go
    cmd()
  File "/nfs/04/osu4914/opt/lib/python2.6/site-packages/solvcon/command.py", line 720, in __call__
    wkr.run(('0.0.0.0', 0), DEFAULT_AUTHKEY)    # FIXME
  File "/nfs/04/osu4914/opt/lib/python2.6/site-packages/solvcon/rpc.py", line 164, in run
    self.eventloop()
  File "/nfs/04/osu4914/opt/lib/python2.6/site-packages/solvcon/rpc.py", line 120, in eventloop
    self._eventloop()
  File "/nfs/04/osu4914/opt/lib/python2.6/site-packages/solvcon/rpc.py", line 99, in _eventloop
    ret = method(*ntc.args, **ntc.kw)
  File "/nfs/04/osu4914/opt/lib/python2.6/site-packages/solvcon/rpc.py", line 264, in create_solver
    blk = dio.load_block(dirname=dirname, blkid=iblk, bcmapper=bcmap)
  File "/nfs/04/osu4914/opt/lib/python2.6/site-packages/solvcon/io/domain.py", line 425, in load_block
    return self.dmf.load_block(dirname, blkid, bcmapper)
  File "/nfs/04/osu4914/opt/lib/python2.6/site-packages/solvcon/io/domain.py", line 226, in load_block
    stream = open(dompath, 'rb')
IOError: [Errno 2] No such file or directory: '/fs/pvfs/osu4914/mesh.feanor/jcf_28mm_p66.dom/domain.dom'

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/36

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

For domain decomposition (solvcon.domain), current implementation stores the original, whole block as a real file. The whole block in domain directory is exactly the same as the source block file. For large meshes, duplicated whole block costs up to tens of GBs.

There should be an option to let solvcon.io.domain.DomainIO to use symlink instead of real file for the whole block. This saves both space and time for splitting.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/32

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/4

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Currently PMarchSave drops anchors on remote Solver to output VTU file. There are two drawbacks: (i) I will be difficult to alter output frequency after initialization. (ii) It is difficult to measure time for output. The control of output VTU should be got back to the PMarchSave hook.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/8

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

For meshes generated by Cubit, domain decomposition doesn't always work. It usually fails for with more than 7 sub-domains. Only hex is tested.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/25

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

There is a need for a "through" BC treatment. A through BC works just like an interface BC, but is connecting within a sub-domain. A through BC will facilitate "turning off" a certain interior boundary, such as diaphragm rupture.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/40

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Loading...

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/21

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

METIS 4 uses int to specify number of bytes when calling malloc(). Allocation fails on splitting meshes with larger than 40 million cells. The error message is as following:

$ scg mesh jcf_33mm.blk jcf_33mm_p32.dom --split=32
I/O formats are determined as: BlockIO, DomainIO.
Load jcf_33mm.blk (BlockIO) ... done. (161.375s)
Block information:
  [Block (3D): 41540592 nodes, 123869747 faces (748750 BC), 41165124 cells]
    [BC#0 "jet": 847 faces with 0 values]
    [BC#1 "upstream": 74529 faces with 0 values]
    [BC#2 "downstream": 74529 faces with 0 values]
    [BC#3 "side": 298116 faces with 0 values]
    [BC#4 "top": 150788 faces with 0 values]
    [BC#5 "wall": 149941 faces with 0 values]
  Cell groups:
    grp#0: 
    grp#1: 
    grp#2: 
  Cell volume (min, max, all): 1.03889e-05, 7.50198e-05, 1458.
Create domain ... done. (1.5974e-05s)
Partition graph into 32 parts ... Error! ***Memory allocation failed for SetUpCoarseGraph: gdata. Requested size: -1987870220 bytesAborted

The mesh is generated by using Cubit with the attached journaling file. Increasing the number of cells increases the Requested size in the error message. Further increasing the number of cells makes allocation of other arrays fails.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/26

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/17

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

The current implementation of solvcon.io.netcdf assumes large format (>2GB) is not used in netCDF. It forbids use of large mesh.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/24

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/15

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/23

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

No real code uses FortranType. The class should be removed.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/27

Originally reported by: David Bilyeu (BitBucket: david_b, GitHub: david_b)

When I attempted to install VTK using the ground makefile I received an error that it could not find Python.h.

To remedy this I ran ccmake and added both the Python library and include directories.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/44

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

While loading Collective object, the whole block currently must be also loaded. For large mesh this causes using too much memory.

Loading whole block should be optional.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/34

Originally reported by: David Bilyeu (BitBucket: david_b, GitHub: david_b)

I have found that it can take a long to to generate a mesh file when I use Cubit from inside Solvcon. It does not always happen but when it does it can take over a minute to generate a ~4k mesh. This the the traceback when I force Solvcon to quit via Ctrl C.

#!python
^CTraceback (most recent call last):
  File "../../scg", line 11, in <module>
    solvcon.go()
  File "/home/david/Programs/dunadan/solvcon/solvcon/cmdutil.py", line 176, in go
    cmd()
  File "/home/david/Programs/dunadan/solvcon/solvcon/command.py", line 735, in __call__
    func(submit=False, **funckw)
  File "/home/david/Programs/dunadan/solvcon/solvcon/case.py", line 383, in simu
    case.init(level=runlevel)
  File "/home/david/Programs/dunadan/solvcon/solvcon/case.py", line 514, in init
    loaded = self.load_block()
  File "/home/david/Programs/dunadan/feanor/euler.py", line 464, in load_block
    blk = super(EulerCase, self).load_block()
  File "/home/david/Programs/dunadan/solvcon/solvcon/case.py", line 589, in load_block
    obj = self.io.mesher(self)
  File "/home/david/Programs/dunadan/feanor/arrangement_euler_ASM_C16.py", line 34, in mesher
    return gn.toblock(bcname_mapper=cse.condition.bcmap)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/46

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

The str_path hard-coded two rc files: .bashrc_path and .bashrc_acct. They should be parameterized.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/16

Originally reported by: David Bilyeu (BitBucket: david_b, GitHub: david_b)

If the number of time steps is not an integer multiple of psteps then the final results are not saved to a vtk file.
e.g if nsteps = 249 and ssteps=20 then the final vtk write will be at the 240th time step.

I provided a simple fix for this in my fork of SOLVCON
https://bitbucket.org/david_b/solvcon_david/src/9e2198a16f9f/solvcon/hook.py#cl-441

I know that it works for a serial case but I don't know if it will work in parallel.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/49

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/43

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/10

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/3

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

The value given by VTK-based visualizing operations is incorrect.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/12

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Restart is needed for large simulations.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/37

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Time spent in solvcon.domain.Collective.build_interface() increases with the number of sub-domains to be split and mesh size. Also, for small meshes, build_interface() just takes a small fraction of time. For large meshes (~50M), build_interface() takes significant time.

Because large meshes are usually desired to be split into more sub-domains than smaller meshes, build_interface() then dominates the time of domain splitting.

Algorithm in build_interface() should be revised for speed up.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/33

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/18

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/22

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

When using SOLVCON with MVAPICH2, sometimes memory allocation error happens. One solution suggested by Lisandro, the author of mpi4py, is to use MPI-enabled Python executable/frontend.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/5

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/7

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Names of soln and dsoln arrays are hard-coded in solvcon.hook.MarchSave.data(), see https://bitbucket.org/yungyuc/solvcon/src/03a428be0f3e/solvcon/hook.py#cl-557 . soln and dsoln are not generic to all solvers and shouldn't be hard-coded in SOLVCON core.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/38

Originally reported by: Anonymous

when i run the script, the message as follow:

[*******@centostoy elcv2d]$ ./go run

*** Start init (level 0) elcv2d ...

*** *** Start build_domain ...

*** *** mesh file: None

*** *** *** Start create_block ...

*** *** *** Traceback (most recent call last):
File "./go", line 247, in
solvcon.go()
File "/usr/lib/python2.6/site-packages/solvcon/cmdutil.py", line 176, in go
cmd()
File "/usr/lib/python2.6/site-packages/solvcon/command.py", line 735, in call
func(submit=False, **funckw)
File "/usr/lib/python2.6/site-packages/solvcon/case.py", line 383, in simu
case.init(level=runlevel)
File "/usr/lib/python2.6/site-packages/solvcon/case.py", line 514, in init
loaded = self.load_block()
File "/usr/lib/python2.6/site-packages/solvcon/case.py", line 589, in load_block
obj = self.io.mesher(self)
File "./go", line 115, in mesher
return gn.toblock(bcname_mapper=cse.condition.bcmap)
AttributeError: 'NoneType' object has no attribute 'toblock'

Some example can run, such as example/euler/impl. Could you tell me the reason. Thank you.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/47

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

The test mesh file is at: http://www.public.iastate.edu/~zjw/hiocfd/bump/bump_tri_level1.msh .

The format is described at: http://www.geuz.org/gmsh/doc/texinfo/gmsh.html#MSH-ASCII-file-format

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/45

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

In https://bitbucket.org/yungyuc/solvcon/src/43854882583c/src/gasdyn/process_physics.cu#cl-133 , the value is not calculated as temperature, but rather the product of temperature and ideal gas constant. It should be fixed.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/41

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/14

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/6

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Currently, BlockInfoHook output performance measure at the end of simulation. It is cumbersome if sometimes the simulation is stopped before executed to the end, and then no performance data is output.

Performance information should be output periodically to prevent loss of information.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/1

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Because cuse operates on GPU memory, for ISV and I/O, data need to be downloaded from GPU device. An Anchor should be added to cuse module for unifying the download.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/29

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

The numbers of edges of hexahedron and tetrahedron listed in solvcon.block are wrong. See https://bitbucket.org/yungyuc/solvcon/src/69ce88dca75a/solvcon/block.py#cl-31

A hexahedron should have 12 edges and a tetrahedron should have 6 edges. The wrongly specified edge numbers do not result into any errors in computation since the numbers are never used (nor tested).

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/42

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

Visualization needs point-based data, while the CESE method gives cell-based solution. The cell to point distributing algorithm should make use of multi-theading or streaming for highest possible efficiency. Visualizing codes should make use of the distributor.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/11

Originally reported by: Yung-Yu Chen (BitBucket: yungyuc, GitHub: yungyuc)

For running with large meshes, it's not easy to requeue the job to correct time_increment. There should be a way to dynamically change time_increment when the case is running.

• Bitbucket: https://bitbucket.org/solvcon/solvcon/issue/35