A new user

[Nathan Woods]

Thought you'd like to know that someone else cares. I've been trying
to get your program working on OS X and Debian. Unfortunately, the
nose tests keep failing. Any thoughts?

I'm interested in your code, both to verify my own work and perhaps to
build on the framework. I'd love to talk, if you're interested.

Nathan Woods
University of Colorado

[Yung-Yu Chen]

Hello Nathan,

You can just paste the error message here and let us see what went wrong.  One usual cause is missing the setup of you ssh public keys authentication.

It's very good to know you are interested in SOLVCON.  I'd love to learn more about your thoughts about the framework, and look forward to potential collaboration.

with regards,

Yung-Yu Chen

--
You received this message because you are subscribed to the Google Groups "solvcon" group.
To post to this group, send email to sol...@googlegroups.com.
To unsubscribe from this group, send email to solvcon+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/solvcon?hl=en.

--
Yung-Yu Chen
http://solvcon.net/yyc/

[Nathan Woods]

Thanks for pointing out the authentication issue. There is a further
problem where OS X uses .dylib files for shared libraries, rather
than .so files. This causes file-not-found failures when attempting to
load .so libraries. So far as I can tell, one fix is to simply
symbolically link the .so files to .dylib files, and it seems to
continue. Is it possible to simply search for .dylib files instead, or
is that a Python thing?

Nathan

On Dec 17, 8:42 pm, Yung-Yu Chen <y...@solvcon.net> wrote:
> Hello Nathan,
>
> You can just paste the error message here and let us see what went wrong.
>  One usual cause is missing the setup of you ssh public keys authentication.
>
> It's very good to know you are interested in SOLVCON.  I'd love to learn
> more about your thoughts about the framework, and look forward to potential
> collaboration.
>
> with regards,
> Yung-Yu Chen
>

[Yung-Yu Chen]

Dear Nathan,

I created a patch to try to fix this issue.  You can download the patch at https://bitbucket.org/yungyuc/solvcon/issue-attachment/54/yungyuc/solvcon/1324333076.7/54/dylib and track the issue at https://bitbucket.org/yungyuc/solvcon/issue/54/shared-objects-are-not-found-under-mac-os .

To apply the patch, go to the top directory of SOLVCON and run "patch -p1 < dylib".  The issue is certainly not the Python thing, but related to the incomplete detection of shared object files in SOLVCON.  The patch tries to fix the detection code in the function solvcon.dependency.loadcdll().

Please let me know if the patch works, and then I can incorporate it into the main stream.

Thanks.

with regards,

Yung-Yu Chen

[Nathan Woods]

That fixed a lot, but not everything. I'm sending you the output files
in an email, in order to not clutter this too badly.

There are a bunch of errors about not finding gambit, or not being
able to import name gambit.

libnetcdf.so and libsc_solvcontest.so are also not being found, which
I have as .dylib files.

Finally, I'm seeing some lines that say ValueError: ('127.0.0.1',
65236) != ('localhost', 65236). I've checked the /etc/hosts file, and
included it below.

There are three errors which I don't know a lot about, which I have
also included below.

Thanks again for your help and your quick responses.

Nathan

/etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE......EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE............EEEEEE.................................................................E.....EEProcess
Process-6:
Traceback (most recent call last):
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
self.run()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "solvcon/rpc.py", line 164, in run
self.eventloop()
File "solvcon/rpc.py", line 120, in eventloop
self._eventloop()
File "solvcon/rpc.py", line 90, in _eventloop
ntc = self.conn.recv()
File "solvcon/connection.py", line 133, in recv
return self.conn.recv(*args, **kw)
EOFError
EEESEProcess Process-15:
Traceback (most recent call last):
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
. self.run()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "solvcon/rpc.py", line 164, in run
self.eventloop()
File "solvcon/rpc.py", line 120, in eventloop
self._eventloop()
File "solvcon/rpc.py", line 90, in _eventloop
ntc = self.conn.recv()
File "solvcon/connection.py", line 133, in recv
return self.conn.recv(*args, **kw)
EOFError
.S....EEE...........................................E...SSSSSS...............SSS
======================================================================

..................... (intervening errors, described above)

======================================================================
ERROR: test_dsoln (solvcon.tests.test_case.TestRemoteParallel)
----------------------------------------------------------------------
Traceback (most recent call last):
File "solvcon/tests/test_case.py", line 205, in test_dsoln
batch=Localhost, rkillfn='')
File "solvcon/tests/test_case.py", line 100, in _get_case
case.init()
File "solvcon/case.py", line 541, in init
self.solver.dealer = self._create_workers()
File "solvcon/case.py", line 731, in _create_workers
create_workers(dealer, nblk)
File "solvcon/case.py", line 777, in _create_workers_remote
dealer.appoint(node.address, port, authkey)
File "solvcon/rpc.py", line 414, in appoint
conn = Client(address=(inetaddr, port), authkey=authkey)
File "solvcon/connection.py", line 178, in Client
skt.connect(address)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 22] Invalid argument
-------------------- >> begin captured stdout << ---------------------

On Dec 19, 3:23 pm, Yung-Yu Chen <y...@solvcon.net> wrote:
> Dear Nathan,
>

> I created a patch to try to fix this issue.  You can download the patch athttps://bitbucket.org/yungyuc/solvcon/issue-attachment/54/yungyuc/sol...
> track the issue athttps://bitbucket.org/yungyuc/solvcon/issue/54/shared-objects-are-not...

>  .
>
> To apply the patch, go to the top directory of SOLVCON and run "patch -p1 <
> dylib".  The issue is certainly not the Python thing, but related to the
> incomplete detection of shared object files in SOLVCON.  The patch tries to
> fix the detection code in the function solvcon.dependency.loadcdll().
>
> Please let me know if the patch works, and then I can incorporate it into
> the main stream.
>
> Thanks.
>
> with regards,
> Yung-Yu Chen
>

[David Bilyeu]

Hi
Welcome to SOLVCON

With all of those errors I think that you might be missing a
dependency.
have you installed everything here
https://bitbucket.org/yungyuc/solvcon/src/90fb53f2b490/README.rst#cl-51
and
https://bitbucket.org/yungyuc/solvcon/src/90fb53f2b490/README.rst#cl-175
?
These directions are for linux so they may or may not work for Macs
have you added yourself to
$HOME/.ssh/authorized_keys
e.g.
ssh-keygen
cat id_rsa.pub > $HOME/.ssh/authorized_keys

you should also install ssh-server

you can test to see if the ssh server was set up correctly by
ssh localhost
This should let you log into the computer without entering a password.
This does depend on how you set up the the keygen.

Hope this helps

David

[Yung-Yu Chen]

Thanks for the error log.  I made another patch to fix the netcdf error.  You can download it at https://bitbucket.org/yungyuc/solvcon/issue-attachment/54/yungyuc/solvcon/1324390805.06/54/dylib2 .  Please apply the new dylib2 patch after applying the old dylib patch (https://bitbucket.org/yungyuc/solvcon/issue-attachment/54/yungyuc/solvcon/1324333076.7/54/dylib).

The gambit error is mysterious.  It seems that somehow your solvcon/io/gambit.py file is missing.  Can you help me to check what files do you have in the directory solvcon/io/?

Thank you for your help.

yyc

[Nathan Woods]

I did a fresh install of Solvcon. The patches fixed all of the .so
problems except for libnetcdf, which still throws errors.

I believe the "127.0.0.1 != localhost" error is due to Mac OS Lion
redefining localhost as seen above. My reasoning is that, when testing
ssh localhost as suggested, it originally said:
"The authenticity of host 'localhost (::1)' can't be established."
That said, "ssh 127.0.0.1" works as expected.

The gambit error is strange, as you mentioned. Gambit.py and
gambit.pyc are in solvcon/io/, as they should be. I did a quick test
with the interpreter, and the commands "import solvcon.io.gambit" and
"from solvcon.io.gambit import GambitNeutral" both work fine.

Nathan

On Dec 20, 7:24 am, Yung-Yu Chen <y...@solvcon.net> wrote:
> Thanks for the error log.  I made another patch to fix the netcdf error.

>  You can download it athttps://bitbucket.org/yungyuc/solvcon/issue-attachment/54/yungyuc/sol....

>  Please apply the new dylib2 patch after applying the old dylib patch

> (https://bitbucket.org/yungyuc/solvcon/issue-attachment/54/yungyuc/sol...

> ).
>
> The gambit error is mysterious.  It seems that somehow your
> solvcon/io/gambit.py file is missing.  Can you help me to check what files
> do you have in the directory solvcon/io/?
>
> Thank you for your help.
>
> yyc
>

[Yung-Yu Chen]

On Wed, Dec 21, 2011 at 05:08, Nathan Woods <charles...@colorado.edu> wrote:

I did a fresh install of Solvcon. The patches fixed all of the .so
problems except for libnetcdf, which still throws errors.

Another possibility is that your netcdf installation is not compatible to my test environment.  The dylib2 patch assumes there is a shared object for netcdf called libnetcdf.dylib .  If the netcdf on OSX does not name its shared object in that way, SOLVCON can't find the file.

However, if you do not use Cubit to generate meshes in the genesis/exodusII format that's depends on netcdf, it's safe to ignore errors about netcdf.

 

I believe the "127.0.0.1 != localhost" error is due to Mac OS Lion
redefining localhost as seen above. My reasoning is that, when testing
ssh localhost as suggested, it originally said:
"The authenticity of host 'localhost (::1)' can't be established."
That said, "ssh 127.0.0.1" works as expected.

If you do not use the built-in transport layer for poor-man's message-passing, it's safe to ignore the error.  SOLVCON supports using external MPI library, and in the future (https://bitbucket.org/yungyuc/solvcon/wiki/Milestone) SOLVCON will have a tighter couple with MPI.

 

The gambit error is strange, as you mentioned. Gambit.py and
gambit.pyc are in solvcon/io/, as they should be. I did a quick test
with the interpreter, and the commands "import solvcon.io.gambit" and
"from solvcon.io.gambit import GambitNeutral" both work fine.

Do you use the released version or install from the repository?

It's safe to ignore the gambit error if you do not use Fluent Gambit to generate meshes in the neutral format.

Thanks.

yyc

[Yung-Yu Chen]

On Wed, Dec 21, 2011 at 05:08, Nathan Woods <charles...@colorado.edu> wrote:

I did a fresh install of Solvcon. The patches fixed all of the .so
problems except for libnetcdf, which still throws errors.

Thanks for the second error log.  It seems that the dylib2 patch didn't work as expected on your machine.  In lines 31--39 of solvcon/io/netcdf.py you should get:

_libs = dict()

def get_lib(path):

    from ctypes import CDLL

    from ..dependency import guess_dllname

    if path in _libs:

        lib = _libs[path]

    else:

        lib = _libs[path] = CDLL(guess_dllname('netcdf'))

    return lib

But in the second error file you sent to me you still have 

    lib = _libs[path] = CDLL('libnetcdf.so')

at the 37th line of solvcon/io/netcdf.py (see the 443th line of the error file).

yyc

[Nathan Woods]

Okay, I found some more information.

First, the gambit error goes away if I run the tests from outside of
the solvcon root directory. Not sure why.

Second, the libnetcdf library was installed in /opt/local/lib, which I
suppose wasn't being searched. This is a MacPorts thing, to keep
everything they install separate from the main system. I created a
symlink in /usr/local/lib, and the problem was resolved. A better
approach would be to include /opt on the linker search path, I
believe.

I'm not sure what to do about the 127.0.0.1 error; as you say, it's
going away soon anyway.

Finally, there were two more (see below). I'm actually not sure if the
first is an error itself, or just an overall "there was an error
somewhere" message. The second one is similarly cryptic.

I'll be poking through the "Getting Started with SOLVCON" tutorial
(which should really be linked to on the main solvcon page; I only
found it through Google) to get a feel for what its capabilities are.
My work is with dynamic, structured grids, and I know that SOLVCON was
not designed with that in mind, but I think that I can at least use it
as an example, in the event that what I want to do is not compatible
with SOLVCON itself. I'm sure I'll have a lot more questions once I've
gotten started.

Nathan

.......................................................................................................................................................................................EEEEESProcess

Process-15:
Traceback (most recent call last):
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap

self.run()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)

File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/rpc.py", line 164, in run
self.eventloop()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/rpc.py", line 120, in eventloop
self._eventloop()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/rpc.py", line 90, in _eventloop
ntc = self.conn.recv()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/connection.py", line 133, in recv
return self.conn.recv(*args, **kw)
EOFError
E..S...................................................E...SSSSSS...............SSS

======================================================================
ERROR: test_dsoln (solvcon.tests.test_case.TestRemoteParallel)
----------------------------------------------------------------------
Traceback (most recent call last):

File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/tests/test_case.py", line 205, in
test_dsoln
batch=Localhost, rkillfn='')
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/tests/test_case.py", line 100, in
_get_case
case.init()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/case.py", line 541, in init
self.solver.dealer = self._create_workers()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/case.py", line 731, in
_create_workers
create_workers(dealer, nblk)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/case.py", line 777, in
_create_workers_remote
dealer.appoint(node.address, port, authkey)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/rpc.py", line 414, in appoint

conn = Client(address=(inetaddr, port), authkey=authkey)

File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/site-packages/solvcon/connection.py", line 178, in

Client
skt.connect(address)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/
lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
error: [Errno 22] Invalid argument
-------------------- >> begin captured stdout << ---------------------

On Dec 20, 3:40 pm, Yung-Yu Chen <y...@solvcon.net> wrote:

> > > > > > To unsubscribe from this group, send email to...
>
> read more »

[Yung-Yu Chen]

On Wed, Dec 21, 2011 at 08:40, Nathan Woods <charles...@colorado.edu> wrote:

Okay, I found some more information.

First, the gambit error goes away if I run the tests from outside of
the solvcon root directory. Not sure why.

If you run the tests by using python2.7 -c 'import solvcon; solvcon.test()' then indeed you have to do it outside the solvcon source directory or there will be tons of errors due to namespace collision.  I haven't totally figured out why, but since Python 2.7 posted a more strict rule on namespace than older Python versions, it could be something we have to live with.

To run unittests in the source tree we have to use nosetests instead.

If you got the errors by running nosetests in the source tree, then I am still clueless.  Maybe it were a  problem specific to OSX or MacPort.  I don't know.

 

Second, the libnetcdf library was installed in /opt/local/lib, which I
suppose wasn't being searched. This is a MacPorts thing, to keep
everything they install separate from the main system. I created a
symlink in /usr/local/lib, and the problem was resolved. A better
approach would be to include /opt on the linker search path, I
believe.

I see.  Thank you very much for the information.  libnetcdf is loaded through ctypes (of Python) in SOLVCON, and ctypes relies on the system dll loader.  So a good way to resolve this issue indeed could be to modify the system link search path.

 

I'm not sure what to do about the 127.0.0.1 error; as you say, it's
going away soon anyway.

There's still a not-short way to go before I can revamp the message-passing in SOLVCON to throw away the hand-crafted transport layer :)  But since distributed-memory parallel computing makes much more sense on Linux (most supercomputers/clusters run Linux instead of OSX), the localhost error shouldn't be any problem at all.  Further, for using enough nodes on a cluster (hundreds to thousands), we usually enable the MPI mode.

Finally, there were two more (see below). I'm actually not sure if the
first is an error itself, or just an overall "there was an error
somewhere" message. The second one is similarly cryptic.

They are related to the hand-crafted transport layer.  You can use nosetests -v to increase the verbosity to verify.  As mentioned above, I don't worry too much about the errors on the transport layer on OS X.

 

I'll be poking through the "Getting Started with SOLVCON" tutorial
(which should really be linked to on the main solvcon page; I only
found it through Google) to get a feel for what its capabilities are.

You are absolutely correct!  It's strange that the idea have never come up in my mind.  Duh!  I will modify the frontpage.

 

My work is with dynamic, structured grids, and I know that SOLVCON was
not designed with that in mind, but I think that I can at least use it
as an example, in the event that what I want to do is not compatible
with SOLVCON itself. I'm sure I'll have a lot more questions once I've
gotten started.

Are you working on the moving grids or the oversets?  The work sounds very interesting.  There's no plan to implement moving grids nor oversets in SOLVCON yet, simply because too many prerequisites (about coding) haven't be met.  We'd be certainly love to know any questions you'd have and discuss with you.

yyc

[Nathan Woods]

I'm glad I was able to help out somewhat with the testing. I first
heard about your work at the AIAA CFD conference this summer, and I've
been meaning to check it out ever since. I'm glad I finally have some
time to do so.

The work I'm doing is the application of moving grids to design
problems. The motion of the grid is usually tied to the fluid velocity
field in some way, thus automatically generating a flow-aligned grid.
The whole thing is based on Hui's Unified Coordinate System (Hui, "The
Unified Coordinate System in Computational Fluid Dynamics"). A movie
of a transonic ramp flow I solved is available at
http://www.youtube.com/watch?v=g-a9oGpKiEw, if you'd like to take a
look.

Up till now, I've been testing and developing with prototype F90 codes
I've written myself, but they've all been fairly rudimentary. It's
actually not that drastic of a change from normal CFD. I just need a
general equation solver and the capacity to dynamically add/remove
blocks (in the block-structured-grid sense, nodes in the unstructured
sense) during the computation.

If it fits well enough with the project, I'd like to try and implement
some of this functionality in SOLVCON. One of the things I'm trying to
figure out is how difficult such modifications would be, given the
current and future state of the project. Specifically, how hard would
it be to modify SOLVCON to run structured grids, and to add/remove
either individual grid points or blocks of points?

Nathan Woods

On Dec 21, 1:51 pm, Yung-Yu Chen <y...@solvcon.net> wrote:

> > > > > > # when the system is booting.  Do not change this entry....
>
> read more »

[Yung-Yu Chen]

On Fri, Dec 23, 2011 at 06:50, Nathan Woods <charles...@colorado.edu> wrote:

I'm glad I was able to help out somewhat with the testing. I first
heard about your work at the AIAA CFD conference this summer, and I've
been meaning to check it out ever since. I'm glad I finally have some
time to do so.

The work I'm doing is the application of moving grids to design
problems. The motion of the grid is usually tied to the fluid velocity
field in some way, thus automatically generating a flow-aligned grid.
The whole thing is based on Hui's Unified Coordinate System (Hui, "The
Unified Coordinate System in Computational Fluid Dynamics"). A movie
of a transonic ramp flow I solved is available at
http://www.youtube.com/watch?v=g-a9oGpKiEw, if you'd like to take a
look.

It is interesting.  Do you have a plan to extend it to 3D?

 

Up till now, I've been testing and developing with prototype F90 codes
I've written myself, but they've all been fairly rudimentary. It's
actually not that drastic of a change from normal CFD. I just need a
general equation solver and the capacity to dynamically add/remove
blocks (in the block-structured-grid sense, nodes in the unstructured
sense) during the computation.

If it fits well enough with the project, I'd like to try and implement
some of this functionality in SOLVCON. One of the things I'm trying to
figure out is how difficult such modifications would be, given the
current and future state of the project. Specifically, how hard would
it be to modify SOLVCON to run structured grids, and to add/remove
either individual grid points or blocks of points?

The very issue SOLVCON wants to resolve is the overhead of implementing supportive functionalities of conservation-law solvers, e.g., unstructured meshes and message-passing.  Extending SOLVCON to use structured meshes or pure Cartesian meshes is doable, but it demands a thorough design like what's been done for the unstructured meshes.

I my experience, CFD codes that uses the structured meshes with curvilinear coordinate system is more complex than codes using the unstructured meshes.  Because the unstructured meshes can always use the Cartesian coordinate system, it does not need to do coordinate transform in the calculation.  Further, load balancing of the unstructured meshes can use graph partitioning, while that of the structured meshes relies on the technique of multi-block.

It should be fairly difficult to extend SOLVCON to use anything other than the unstructured meshes, which currently is the foundation of the whole framework.  The developer needs to know quite well about SOLVCON's internal structure to reassemble the building blocks.  

I keep using "extend" instead of "modify" because simply modifying SOLVCON for another mesh definition wastes the extensibility offered by the software framework.

Having said that, I do consider to support pure Cartesian meshes in SOLVCON, though I don't have time to code it.  Pure Cartesian meshes offers superior runtime efficiency for simple geometry, and is useful in some application areas.

I will be very willing to discuss this with you in more detail, if you are interested in the work.

yyc

 

>
> read more »

--
You received this message because you are subscribed to the Google Groups "solvcon" group.
To post to this group, send email to sol...@googlegroups.com.
To unsubscribe from this group, send email to solvcon+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/solvcon?hl=en.