Hi Xueyu, all,
I just took a closer look at gmsh , by Christophe Geuzaine and J-F Remacle.
This closer look has led me to believe that instead of (or perhaps in addition
to) a node-pushing approach to creating curved elements, we should probably
create a facility for importing high-order meshes from gmsh. In contrast to
the mesh generators we have at present, gmsh appears to support genuine high-
order mesh generation by allowing a curvilinear description of the domain, and
then spitting out curved elements conforming to this domain description. Its
description language is a bit bizarre, but actually quite flexible.
This work would start by building a two-way interface from MeshPy to gmsh,
allowing mesh specification from and import into Python, and then progress
towards making the necessary changes to hedge.
As a further benefit, gmsh interoperates natively with Madlib , which could
allow us to do high-order mesh adaptation relatively cheaply.
On Donnerstag 15 Oktober 2009, Field, Scott wrote:
> Hi All...
> Today I tried updating my master branch following the steps on the wiki
> executing ./repotool develop
> results in the following error message
> Scanning installed packages
> Setuptools installation detected at /users/sfield/src/pytools
> Non-egg installation
> Removing elements out of the way...
> Already patched.
> /users/sfield/src/pytools/setuptools-0.6c9-py2.6.egg-info already patched.
> Extracting in /tmp/tmprTQZOK
> Now working in /tmp/tmprTQZOK/distribute-0.6.4
> Building a Distribute egg in /users/sfield/src/pytools
> /users/sfield/src/pytools/setuptools-0.6c9-py2.6.egg-info already exists
> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
> or: setup.py --help [cmd1 cmd2 ...]
> or: setup.py --help-commands
> or: setup.py cmd --help
> error: invalid command 'develop'
> This was on hpcgeek, where I am using python version 2.6.1. Is this
> related to the past few emails involving setuptools? B/c Im using 2.6.1 I
> was hoping those emails didnt concern me :)
> Has anyone encountered this problem? Will removing setuptools fix it?
I've replaced setuptools and virtualenv with distribute and virtualenv-
distribute in the shared install set on hpcgeek. If you do
now, you should be ok. Sorry for the trouble.
This is relevant to you if you are using Python 2.6.3 and you are getting
errors of the sort:
line 85, in get_ext_filename
It seems Python 2.6.3 broke every C/C++ extension on the planet that was
shipped using setuptools (which includes PyCUDA, PyOpenCL, and many more of my
packages.) Thanks for your patience as I've worked through this mess, and to
both Allan and Christine, I'm sorry you've had to deal with this, and thanks
to Allan for pointing me in the right direction.
To make a long story short, I've switched my packages (including PyCUDA) to
use distribute instead of setuptools. All these changes are now in git. I'm
not sure this will help if a 2.6.3 user already has setuptools installed, but
I hope it will at least not make any other case worse. All in all, this seems
like the least bad option given that I expect distribute to be "the way of the
Before I unleash this change full-scale, I would like it to get some testing.
For this purpose, I've created a PyCUDA release candidate package, here:
PLEASE TEST THIS, and speak up if you do--both positive and negative comments
are much appreciated.
PS: Once I have reasonable confirmation that this works for PyCUDA, I'll also
release updated versions of PyOpenCL, meshpy, boostmpi, pyublas, .... The
relevant changes are *already in git* if you'd like to try them now.
PPS: Deciding in favor of distribute and against the promised setuptools
update was based on two factors:
- Primarily, distribute makes a fix for the 2.6.3 issue available *now*.
- Secondarily, I personally disliked the behavior of PJE, the author of
setuptools, in response to the current mess.
Hi, Andreas and everyone
I have several questions on hedge:
1. did hedge compute 'Fscale' in P196 of Jan's Book? if yes, where I can
2. in the discretization,py, stiffness_coefficients are computed? where are
3 what's the element_groups.ranges for? I know it stores the DOF for each
element, but why not choose a variable to store it instead of c++ object?