-
-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test: coarray_navier_stokes fails #42
Comments
Thanks for submitting this issue. If that is the only test failing, then it is very likely that your build is correct. I'll therefore assume this is not a critical issue for you and it will be several days before I have a chance to investigate this further. |
I am able to recreate the same behavior on a Travis-CI Ubuntu linux environment. Also, it seems that this test isn't even attempted under OS X. Just curious what the reason is for this. |
Made change to the CMake setup, for performing Navier-Stokes tests. The system setup or the machine configuration is identified before performing Navier-Stokes tests. If the machine is identified to be a 64bit (x86-64) system, the Navier-Stokes test is performed or else the case is omitted from the tests. Signed-off-by: naveen-ravi <naveen.namashivayam.r@gmail.com>
…ored and renamed several tests to have more descriptive names or names that indicate we need to a assign more descriptive names.
It's not attempted on OS X because it failed on OS X due to an incompatibility with the FFT routines. As mentioned in the other thread, I'd be glad to switch to other FFTs as the default if it's something you'd like to try. |
@finneyb: Could you please re-run
@afanfa would you mind taking a quick look at this error message on the Travis-CI build? I'm guessing this is due to an issue with the FFT library, but I'm not sure... I was reading that some people had problems with /dev/urandom on Travis-CI as well, but according to my testing that is not the issue. Here is the log line where the error message starts: https://travis-ci.org/zbeekman/opencoarrays/jobs/96362389#L1301 @afanfa & @rouson my testing on Travis-CI also seems to indicate that |
sorry, forgot the code block. Here it is again.
|
@finneyb Ah, OK. I should have noticed earlier, you're experiencing a completely different issue than I am... @finneyb can you please tell me the output of running It looks like either there may be a problem in the logic of how the navier_stokes test is conditionally compiled and added to the list of tests in the CMakeLists.txt. (It links against an FFT library written directly in assembly, and only works on x86_64 Linux, so the CMake build tries to ensure that the OS and architecture will support the library before compiling and linking the test that requires it.) Some secondary hunches as to where the problem could be are:
I'll try to look into this some more. |
On 12/11/2015 4:37 PM, Izaak Beekman wrote:
uname -mps installed open coarrays with Looks like the installer should just not install that test at all as |
yes I'm a bit confused to why it is being attempted... digging around further.... For now it is certainly safe to ignore that error... the FFT library is not part of OCA just part of the tests... I'm working on fixing this now. |
I can confirm that this test failure is due to the fact that the top level CMakeLists.txt has unintentionally diverged between the master branch and the 1.x branch ( This line is the culprit: https://github.com/sourceryinstitute/opencoarrays/blob/branch-1.0.0/CMakeLists.txt#L137 and it should look like: https://github.com/sourceryinstitute/opencoarrays/blob/master/CMakeLists.txt#L174 |
Branch 1.0.0: enable Travis-CI Also fixes #42 as a side effect
@zbeekman Hi, I am sorry...I couldn't understand what exactly is this issue with the navier_stokes test. I suppose we fixed the issue involving 32-bit vs 64-bit version build. This test was supposed to run on only the 64-bit version Linux build and should be skipped for others. |
@naveen-rn sorry if I confused you. This issue is now resolved. The problem was due to patches being applied to the master branch but not the 1.x release branch. On the 1.x the x86_64 check was applied when building the test but not when adding it. So on @finneyb's arm machine CMake was trying to run the test even though it wasn't built. Some other unrelated problem is occurring on the TravisCI build (this is an Ubuntu virtual machine that reports itself as x86_64) in which a SIGBUS is being raised by attempting to access an invalid memory location during the coarray_navier_stokes test. My hunch is that this is due to a virtualization/architecture issue with the FFT library, but TBH I really don't know the cause for sure. (No compile/link time errors are raised and I can't seem to generate a call stack backtrack with line numbers) For now I disable the test when running on the Travis-CI VMs, but if someone could take a look and figure out the source of the problem I would certainly welcome that. Here is a link to a recent build exhibiting the problem: https://travis-ci.org/zbeekman/opencoarrays/jobs/96362389#L1301 |
Fixed by PR #49 |
In case it helps, you might download the Linux virtual machine that is available in the Sourcery Institute store: http://www.sourceryinstitute.org/store. There are instructions for importing and booting the virtual machine in the free virtualization package VirtualBox available at http://www.virtualbox.org. I will be uploading a slightly improved version of the virtual machine sometime soon -- hopefully tonight. |
Great! I've actually been meaning, for quite a long time to dual boot my MPB, but haven't gotten around to it (for years now...) so I should really take you up on the offer. My one hesitation is that space is at a premium for me right now. However, it seems that you don't have any issues running this test on your VM Linux instance, so I think the issues on Travis-CI with this test must be related to their specific virtualization environment. |
You can store the vm on an USB flash drive. The vm itself expands to about 12 GB when installed. It has limited space so I generally mount a second virtual drive that occupies a bit under 12 GB. To play it safe, a flash drive with a capacity of 32 GB is probably best. Also, it's best if it uses USB 3 for speed. The virtual drive is also online at the URL below and I can provide a link to it via email with instructions for mounting it if you like. Alternatively, I can ask my assistant to mail everything to you on a 32 GB flash drive if you like. If so, let me know. |
I don't think my current MBP supports USB 3, but I'm not 100%. I also have a second drive installed (in place of the cd-dvd drive) so I could probably figure out a way to mount/install it there. I'd just like to catch up on a bunch of the stuff we spoke about on the phone before I undertake installing the Linux VM, if that's OK. The Linux testing is enabled on Travis-CI now, any PRs I submit will be checked there---at least nominally. (All tests besides |
- Prevent having to explicitly run `uname` CMAKE_SYSTEM_PROCESSOR holds the output of `uname -p` which will be x86_64 on all x86_64 Linux machines, and another value on incompatible machines line OS X, arm, etc. - Since this is a CMake variable no scoping/inheritence etc. issues, or concerns about conditional definition etc.
Also, there is a typo in c7022fe that causes the test executable to fail to build, but the test will still try to run... |
Also, limit building dist_transpose more accurately: It should not be built during a CodeCoverage build (`cmake -DCMAKE_BUILD_TYPE=CodeCoverage`) but *can* be built during other Travis-CI tests.
Also, limit building dist_transpose more accurately: It should not be built during a CodeCoverage build (`cmake -DCMAKE_BUILD_TYPE=CodeCoverage`) but *can* be built during other Travis-CI tests.
Also, limit building dist_transpose more accurately: It should not be built during a CodeCoverage build (`cmake -DCMAKE_BUILD_TYPE=CodeCoverage`) but *can* be built during other Travis-CI tests.
On 12/6/2015 10:16 AM, afanfa wrote:
I added the suggested options at the appropriate place in install.sh and then executed install. Running ctest again results in the same error. The directory pde_solvers/navier-stokes is present, but the directory does not contain a file or directory named coarray_navier_stokes
22/22 Testing: coarray_navier_stokes
22/22 Test: coarray_navier_stokes
Command: "/usr/local/bin/mpich/bin/mpiexec" "-np" "2" "/usr/local/bin/opencoarrays/opencoarrays-build/src/tests/integration/pde_solvers/navier-stokes/coarray_navier_stokes"
Directory: /usr/local/bin/opencoarrays/opencoarrays-build
"coarray_navier_stokes" start time: Dec 06 21:03 PST
Output:
[proxy:0:0@madison] HYDU_create_process (/usr/local/bin/mpich-3.1.4/src/pm/hydra/utils/launch/launch.c:75): execvp error on file /usr/local/bin/opencoarrays/opencoarrays-build/src/tests/integration/pde_solvers/navier-stokes/coarray_navier_stokes (No such file or directory)
[proxy:0:0@madison] HYDU_create_process (/usr/local/bin/mpich-3.1.4/src/pm/hydra/utils/launch/launch.c:75): execvp error on file /usr/local/bin/opencoarrays/opencoarrays-build/src/tests/integration/pde_solvers/navier-stokes/coarray_navier_stokes (No such file or directory)
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= PID 26466 RUNNING AT madison
= EXIT CODE: 255
= CLEANING UP REMAINING PROCESSES
= YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
## Test time = 0.03 secTest Fail Reason:
Required regular expression not found.Regex=[Test passed.
]
"coarray_navier_stokes" end time: Dec 06 21:03 PST
"coarray_navier_stokes" time elapsed: 00:00:00
The text was updated successfully, but these errors were encountered: