Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Meeting Minutes for 2015-07-13
by Roland Haas 13 Jul '15

13 Jul '15

Hello all, Present were: Roland, Steve, Elo, Matt, Peter, Josh, Yosef * no objections to including SphericalHarmonicReconGen so it will be included in ET thorn list * new arrangement for elliptic solver thorn. This will likely happen before ET workshop. * workshop: participant list is on the meeting page Yours, Roland

1 0

Einstein Toolkit Meeting Reminder
by Steven R. Brandt 13 Jul '15

13 Jul '15

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/community/support/ In short: the number is (+1) 225-578-4942 and the conference id is 118682#. Steven R. Brandt

1 1

Re: [Users] Reformatting Carpet's source code
by Comer Duncan 13 Jul '15

13 Jul '15

Erik, I agree that the Carruth (sorry for misspelling his name in my previous post!) talk is a good intro to what's currently possible. He is a bit quick but covers many interesting an relevant topics for a developer in the trenches. If clang-format gets adopted by the ET team, then I would recommend a document to lead new users who want to use it through some Cactus-related examples. I also wonder about the following: if users do use Kranc as a thorn construction tool (as I hope becomes a popular choice (although I am at the beginning of learning to use it!)), when Kranc does its thing maybe have clang-format used as a backend so that when users use the Kranc route the resulting code had had the benefit of passing through clang-format. That would seem to help guarantee any new thorns would not have a need to be filtered until the user makes changes to the *.cc files in the thorn. Of course one would want to make sure that the backend clang-formatted files result in executables that are at least as fast as not using clang-format. Comer On Wed, Jul 8, 2015 at 12:36 PM, Erik Schnetter <schnetter(a)cct.lsu.edu> wrote: > On Wed, Jul 8, 2015 at 10:58 AM, Comer Duncan <comer.duncan(a)gmail.com> > wrote: > >> I have recently looked around on this clang-format topic and found the >> interesting talk by Carruthers: >> >> >> https://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C… >> >> It seems impressive. Of course, ordinary ET users (?) may not see that >> the utility has enough merit, but as one who has written sizable numerical >> relativity outside of the ET garden, I can see how using clang-format could >> help a lot with the programming and reading of code. So, for what it's >> worth I hope an effort is made to begin incorporating clang-format into >> _new_ thorns. To this end it would seem reasonable to have an ET-approved >> .clang-format made part and parcel with the ET releases. One could use it >> or not but having it around with some accepted conventions sounds like >> something worth trying. Presumably if clang-format ever sees the light of >> the day in ET releases it would be done first in the development branch. I >> for one would welcome having such tools around. >> > > Yes, thank you! The first half hour of the talk exactly described my > experience, and my arguments above: > - formatting is much more than indenting > - clang-format is amazing > - it saves developers a lot of time > > I'm inclined to make the first half hour of this talk "required reading" > to participate in this discussion... > > -erik > > Comer >> >> On Wed, Jul 8, 2015 at 9:47 AM, Erik Schnetter <schnetter(a)cct.lsu.edu> >> wrote: >> >>> Yes, clang-format is really good; it's playing in a different league >>> than GNU indent or other prehistoric predecessors. It turns out that >>> clang-format does not chase include statements nor requires knowledge about >>> #define statements, and can thus format each file in isolation. It uses >>> clang's parser, but does not construct the detailed semantic tree >>> structures that clang needs to resolve types. Thus clang-format stays >>> closer to how a human reads code than how a compiler interprets it. >>> >>> Yes, older versions of clang-format had problems in some special cases. >>> I've encountered issues in hairy template arguments, where clang-format >>> gets confused about the meaning of "<" (template argument or less-than >>> sign?) and "&&" (binary operator or rvalue prefix?). Newer versions of >>> clang-format get this right; otherwise, one can use parentheses to make the >>> meaning clear. Note that these are really dark corners of C++, where it is >>> impossible to tell the difference without knowing whether certain >>> identifiers are types or variables, which depends on details of scoping and >>> namespaces and all previous include files. >>> >>> Anyway -- we should easily be able to all use the same version of >>> clang-format. >>> >>> -erik >>> >>> On Wed, Jul 8, 2015 at 9:39 AM, Steven R. Brandt <sbrandt(a)cct.lsu.edu> >>> wrote: >>> >>>> On one hand, clang-format ought to be really good because it can >>>> leverage the clang parser and understand the code as well as the compiler. >>>> Other tools have to re-engineer the whole process and may not get it >>>> exactly right. I'm rarely completely happy with auto-format, and because of >>>> that I only ever apply it to small areas of code at a time. >>>> >>>> On the other hand, there is a potential version issue. I just formatted >>>> a simple code with two versions of clang-format I had installed on my >>>> laptop and got different results. The older version messed up the >>>> formatting of a C++11 initializer. While the C++11 issues are probably not >>>> going to be a problem going forward, other issues might crop up. I could >>>> easily imagine bits of formatting changing back and forth as two developers >>>> with different versions of clang updated the source. >>>> >>>> Cheers, >>>> Steve >>>> >>>> >>>> On 07/07/2015 10:51 AM, Erik Schnetter wrote: >>>> >>>> Yeah, that's what I thought in the beginning -- code formatting is all >>>> about indentation, which is handled by the tab key. But it turns out, it >>>> isn't. I only noticed after using clang-format for some way. Code >>>> formatting ties up part of your brain, every time you type a character, you >>>> have to ask yourself "do I need to insert a space", "do not need to insert >>>> a line break", "should I join these two lines again", "does this comments >>>> need re-formatting", "should I line-wrap this lengthy expression >>>> differently", "how do I make these lines line up nicely", etc. >>>> >>>> With clang-format -- none of this. You type in the content you want, >>>> you insert spaces where absolutely necessary, you save, and when you look >>>> again, the code looks nice. And you can relax in the knowledge that this >>>> formatting is a projection -- there's no "other way" that maybe might look >>>> better. >>>> >>>> Also, clang-format doesn't indent namespaces the way the tab key >>>> does, and it doesn't make errors. Clang-format is the complete separation >>>> of form and content, and you only have to care about the latter. Think of >>>> it as latex: You type the text, and it will look well-formatted without >>>> requiring any manual input. You may think that latex isn't necessary and >>>> that manually formatted text will look just as nice -- and you're probably >>>> right, in almost all cases manual formatting would look nice enough to do >>>> the trick. But there is a fundamental difference between latex and manual >>>> formatting, and it's good to have it. >>>> >>>> So: Yes, this is worth it. >>>> >>>> Regarding various versions of clang-format: There are (of course) >>>> also many options you can set, although I just go with the default, which >>>> is very good. Yes, there are probably difference between versions >>>> (improvements, e.g. for handling template arguments). I'm sure we could >>>> settle on a standard version, or a standard set of options. >>>> >>>> -erik >>>> >>>> >>>> On Mon, Jul 6, 2015 at 5:56 PM, Ian Hinder <ian.hinder(a)aei.mpg.de> >>>> wrote: >>>> >>>>> >>>>> On 4 Jul 2015, at 17:06, Erik Schnetter <schnetter(a)cct.lsu.edu> >>>>> wrote: >>>>> >>>>> On Sat, Jul 4, 2015 at 10:30 AM, Ian Hinder <ian.hinder(a)aei.mpg.de> >>>>> wrote: >>>>> >>>>>> >>>>>> On 3 Jul 2015, at 23:33, Erik Schnetter <schnetter(a)cct.lsu.edu> >>>>>> wrote: >>>>>> >>>>>> I've come to like to use a tool to automatically indent and format >>>>>> source code. This has several advantages -- the code has automatically a >>>>>> consistent style, indentation errors become obvious, and one doesn't have >>>>>> to spend time formatting the code manually while coding. >>>>>> >>>>>> clang-format is the best such tool of which I'm aware. It's vastly >>>>>> better than e.g. GNU indent. >>>>>> >>>>>> I propose to re-format Carpet's source code via clang-format. >>>>>> >>>>>> Usually, changing the source code format is disruptive, since >>>>>> patches or local modifications won't apply cleanly any more. However, with >>>>>> clang-format, I don't think that this is an issue -- one can use >>>>>> clang-format on the modified code (e.g. a branch), which should eliminate >>>>>> gratuitous changes. >>>>>> >>>>>> >>>>>> Please comment. >>>>>> >>>>>> >>>>>> Suppose that I have a local branch with a number of commits (I >>>>>> do). If I want to cherry-pick something from the new reformatted master, I >>>>>> could add a new commit to my branch which reformats everything, and >>>>>> cherry-picking would hopefully then be possible. To rebase my branch off >>>>>> of the reformatted master, I would probably have to rebase it off the >>>>>> commit in master before the reformat, then apply the reformatting myself, >>>>>> then rebase again of the new master. So apart from the amount of >>>>>> git-gymnastics needed to do this, it seems OK. More serious would be the >>>>>> utter impossibility of diffing formaline tarballs across the change and >>>>>> identifying the real differences. >>>>>> >>>>>> I hope it doesn't need to be said, but any commits which introduce >>>>>> reformatting should be clearly labeled as such, and should not introduce >>>>>> any other changes, as these will be lost during a rebase in which >>>>>> formatting commits are skipped and formatting run again. >>>>>> >>>>>> With the above considerations, is it worth doing this? >>>>>> >>>>> >>>>> Yes, it definitively is. Not having to worry about indentation and >>>>> formatting while coding frees the mind; it is a transformative experience. >>>>> >>>>> >>>>> I just press TAB in emacs to make sure the indentation is correct; >>>>> it's not something I ever really think about. After reading Roland's >>>>> email, I'm more and more concerned that a large-scale reformatting of an >>>>> existing codebase with several branches owned by different people is going >>>>> to cause a fair amount of pain. For a new project, I would definitely use >>>>> such a system, and when new code is added to an existing project, but I'm >>>>> not sure it's worth the trouble it will cause for Carpet. >>>>> >>>>> -- >>>>> Ian Hinder >>>>> http://members.aei.mpg.de/ianhin >>>>> >>>>> >>>> >>>> >>>> -- >>>> Erik Schnetter <schnetter(a)cct.lsu.edu> >>>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>>> >>>> >>>> _______________________________________________ >>>> Users mailing listUsers@einsteintoolkit.orghttp://lists.einsteintoolkit.org/mailman/listinfo/users >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)einsteintoolkit.org >>>> http://lists.einsteintoolkit.org/mailman/listinfo/users >>>> >>>> >>> >>> >>> -- >>> Erik Schnetter <schnetter(a)cct.lsu.edu> >>> http://www.perimeterinstitute.ca/personal/eschnetter/ >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)einsteintoolkit.org >>> http://lists.einsteintoolkit.org/mailman/listinfo/users >>> >>> >> > > > -- > Erik Schnetter <schnetter(a)cct.lsu.edu> > http://www.perimeterinstitute.ca/personal/eschnetter/ >

3 2

build error at end
by Comer Duncan 08 Jul '15

08 Jul '15

I have tried building ET for the current released version. I am on a macbook pro running Yosemite. The build script is: #!/bin/sh rm -rf configs/sim echo "done removing configs/sim" simfactory/bin/sim build --optionlist=./myoptionlist.cfg --thornlist=./ cospluseinsteintkit.th >build$1.log 2>&1 The build goes along fine apparently until the final executable. I copy below the part after which the build chokes: Creating cactus_sim in /Users/comerduncan/Cactus/exe from EinsteinAnalysis/ADMAnalysis EinsteinBase/ADMBase EinsteinBase/ADMCoupling EinsteinBase/ADMMacros AEIThorns/ADMMass AEIThorns/AEILocalInterp EinsteinAnalysis/AHFinder EinsteinAnalysis/AHFinderDirect ExternalLibraries/BLAS CactusBase/Boundary Cosmology/CT_Analytic Cosmology/CT_MultiLevel EinsteinAnalysis/CalcK Carpet/Carpet Carpet/CarpetEvolutionMask Carpet/CarpetIOASCII Carpet/CarpetIOBasic Carpet/CarpetIOHDF5 Carpet/CarpetIOScalar Carpet/CarpetIntegrateTest Carpet/CarpetInterp Carpet/CarpetInterp2 Carpet/CarpetLib Carpet/CarpetMask Carpet/CarpetProlongateTest Carpet/CarpetReduce Carpet/CarpetRegrid Carpet/CarpetRegrid2 Carpet/CarpetRegridTest Carpet/CarpetSlab Carpet/CarpetTracker CactusBase/CartGrid3D CactusNumerical/Cartoon2D EinsteinBase/Constants CactusBase/CoordBase EinsteinBase/CoordGauge Carpet/CycleClock CactusExamples/DemoInterp CactusNumerical/Dissipation EinsteinInitialData/DistortedBHIVP EinsteinAnalysis/EHFinder EinsteinBase/EOS_Base EinsteinEOS/EOS_Hybrid EinsteinEOS/EOS_IdealFluid EinsteinEOS/EOS_Omni EinsteinEOS/EOS_Polytrope EinsteinExact/EinsteinExact_Test CactusElliptic/EllBase CactusElliptic/EllSOR EinsteinInitialData/Exact EinsteinAnalysis/Extract ExternalLibraries/FFTW3 CactusExamples/FleshInfo CactusUtils/Formaline CactusBase/Fortran EinsteinEvolve/GRHydro EinsteinEvolve/GRHydro_InitData ExternalLibraries/GSL EinsteinExact/GaugeWave KrancNumericalTools/GenericFD ExternalLibraries/HDF5 CactusConnect/HTTPD CactusConnect/HTTPDExtra CactusExamples/HelloWorld Carpet/HighOrderWaveTest EinsteinBase/HydroBase EinsteinAnalysis/Hydro_Analysis EinsteinInitialData/Hydro_InitExcision EinsteinInitialData/IDAnalyticBH EinsteinInitialData/IDAxiBrillBH EinsteinInitialData/IDAxiOddBrillBH EinsteinInitialData/IDBrillData EinsteinInitialData/IDConstraintViolate EinsteinInitialData/IDFileADM EinsteinInitialData/IDLinearWaves CactusWave/IDScalarWave CactusWave/IDScalarWaveC CactusWave/IDScalarWaveCXX CactusWave/IDScalarWaveElliptic CactusExamples/IDWaveMoL CactusBase/IOASCII CactusBase/IOBasic CactusPUGHIO/IOHDF5 CactusPUGHIO/IOHDF5Util CactusIO/IOJpeg CactusBase/IOUtil CactusBase/InitBase CactusNumerical/InterpToArray EinsteinExact/KerrSchild ExternalLibraries/LAPACK ExternalLibraries/LORENE CactusNumerical/LocalInterp CactusNumerical/LocalInterp2 CactusNumerical/LocalReduce Carpet/LoopControl McLachlan/ML_ADMConstraints McLachlan/ML_ADMQuantities McLachlan/ML_BSSN McLachlan/ML_BSSN_Helper McLachlan/ML_BSSN_Test McLachlan/ML_CCZ4 McLachlan/ML_CCZ4_Helper McLachlan/ML_CCZ4_Test McLachlan/ML_WaveToy McLachlan/ML_WaveToy_Test ExternalLibraries/MPI CactusUtils/MemSpeed EinsteinInitialData/Meudon_Bin_BH EinsteinInitialData/Meudon_Bin_NS EinsteinInitialData/Meudon_Mag_NS EinsteinExact/Minkowski CactusNumerical/MoL EinsteinExact/ModifiedSchwarzschildBL EinsteinAnalysis/Multipole CactusUtils/NaNCatcher CactusUtils/NaNChecker EinsteinEvolve/NewRad CactusUtils/Nice EinsteinInitialData/NoExcision CactusUtils/NoMPI CactusNumerical/Noise CactusNumerical/Norms PITTNullCode/NullConstr PITTNullCode/NullDecomp PITTNullCode/NullEvolve PITTNullCode/NullExact PITTNullCode/NullGrid PITTNullCode/NullInterp PITTNullCode/NullNews PITTNullCode/NullPsiInt PITTNullCode/NullSHRExtract PITTNullCode/NullVars ExternalLibraries/OpenSSL EinsteinAnalysis/Outflow ExternalLibraries/PAPI CactusPUGH/PUGH CactusPUGH/PUGHInterp CactusPUGH/PUGHReduce CactusPUGH/PUGHSlab CactusNumerical/Periodic LSUThorns/PeriodicCarpet CactusExamples/Poisson AEIThorns/PunctureTracker LSUThorns/QuasiLocalMeasures Carpet/ReductionTest Carpet/ReductionTest2 Carpet/ReductionTest3 CactusNumerical/ReflectionSymmetry Carpet/RegridSyncTest EinsteinInitialData/RotatingDBHIVP CactusNumerical/RotatingSymmetry180 CactusNumerical/RotatingSymmetry90 CactusExamples/SampleBoundary CactusExamples/SampleIO EinsteinUtils/SetMask_SphericalSurface EinsteinExact/ShiftedGaugeWave CactusNumerical/Slab CactusNumerical/SlabTest CactusConnect/Socket CactusNumerical/SpaceMask PITTNullCode/SphericalHarmonicDecomp PITTNullCode/SphericalHarmonicRecon CactusNumerical/SphericalSurface EinsteinBase/StaticConformal LSUThorns/SummationByParts CactusBase/SymBase AEIThorns/SystemStatistics CactusUtils/SystemTopology CactusElliptic/TATelliptic EinsteinUtils/TGRtensor EinsteinInitialData/TOVSolver CactusUtils/TerminationTrigger CactusTest/TestArrays Carpet/TestCarpetGridInfo CactusTest/TestComplex CactusTest/TestCoordinates CactusTest/TestFortranCrayPointers CactusTest/TestFortranDependencies1 CactusTest/TestFortranDependencies2 CactusTest/TestFpointerNULL CactusTest/TestFreeF90 CactusTest/TestGlobalReduce CactusTest/TestInclude1 CactusTest/TestInclude2 CactusNumerical/TestLocalInterp2 CactusNumerical/TestLocalReduce CactusTest/TestLoop Carpet/TestLoopControl CactusTest/TestMath CactusTest/TestMoL CactusTest/TestPar CactusTest/TestReduce CactusTest/TestSchedule CactusTest/TestStrings CactusTest/TestTable CactusTest/TestTimers CactusTest/TestTypes CactusBase/Time CactusExamples/TimerInfo CactusUtils/TimerReport Carpet/Timers EinsteinBase/TmunuBase AEIThorns/Trigger EinsteinInitialData/TwoPunctures EinsteinExact/Vaidya2 LSUThorns/Vectors CactusWave/WaveBinarySource CactusExamples/WaveMoL CactusExamples/WaveToy1DF77 CactusExamples/WaveToy2DF77 CactusWave/WaveToyC CactusWave/WaveToyCXX CactusWave/WaveToyExtra CactusWave/WaveToyF77 CactusWave/WaveToyF90 CactusWave/WaveToyFreeF90 EinsteinAnalysis/WeylScal4 ExternalLibraries/hwloc ExternalLibraries/libjpeg ExternalLibraries/zlib Formaline: Creating git master repository... Formaline: Pushing source tree to master git repository... Undefined symbols for architecture x86_64: "MPI::Win::Free()", referenced from: vtable for MPI::Win in libthorn_PeriodicCarpet.a(periodic.cc.o) vtable for MPI::Win in libthorn_CT_MultiLevel.a(CT_MultiLevel.cc.o) vtable for MPI::Win in libthorn_Carpet.a(helpers.cc.o) vtable for MPI::Win in libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) vtable for MPI::Win in libthorn_CarpetIOASCII.a(ioascii.cc.o) vtable for MPI::Win in libthorn_CarpetIOBasic.a(iobasic.cc.o) vtable for MPI::Win in libthorn_CarpetIOHDF5.a(Input.cc.o) ... "MPI::Comm::Comm()", referenced from: MPI::Intercomm::Merge(bool) const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Intracomm::Split(int, int) const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Intracomm::Create(MPI::Group const&) const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Graphcomm::Clone() const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Cartcomm::Clone() const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Intracomm::Clone() const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Intracomm::Create_graph(int, int const*, int const*, bool) const in libthorn_PeriodicCarpet.a(periodic.cc.o) ... "MPI::Datatype::Free()", referenced from: vtable for MPI::Datatype in libthorn_PeriodicCarpet.a(periodic.cc.o) vtable for MPI::Datatype in libthorn_CT_MultiLevel.a(CT_MultiLevel.cc.o) vtable for MPI::Datatype in libthorn_Carpet.a(helpers.cc.o) vtable for MPI::Datatype in libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) vtable for MPI::Datatype in libthorn_CarpetIOASCII.a(ioascii.cc.o) vtable for MPI::Datatype in libthorn_CarpetIOBasic.a(iobasic.cc.o) vtable for MPI::Datatype in libthorn_CarpetIOHDF5.a(Input.cc.o) ... "_ompi_mpi_cxx_op_intercept", referenced from: MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CT_MultiLevel.a(CT_MultiLevel.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_Carpet.a(helpers.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CarpetIOASCII.a(ioascii.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CarpetIOBasic.a(iobasic.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CarpetIOHDF5.a(Input.cc.o) ... ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make[1]: *** [/Users/comerduncan/Cactus/exe/cactus_sim] Error 1 make[1]: *** Waiting for unfinished jobs.... Formaline: Pushing to local repository /Users/comerduncan/Cactus/../CactusSourceJar.git... Formaline: Optimising git repository (slow only the first time)... make: *** [sim] Error 2 Is there likely a problem with openmpi again?? Here is some info about the current ports: port installed | grep openmpi Warning: port definitions are more than two weeks old, consider updating them by running 'port selfupdate'. openmpi @1.7.5_3 openmpi-default @1.7.5_3+gcc49 (active) openmpi-default @1.7.5_4+gcc49 openmpi-gcc49 @1.7.5_3+fortran (active) openmpi-gcc49 @1.7.5_4+fortran Note that I had elected to activate openmpi-gcc49 @1.7.5_3+fortran (active) rather than openmpi-gcc49 @1.7.5_4+fortran because with _4 the build crashed. For gcc49 there is: gcc49 @4.9.2_1 gcc49 @4.9.2_2 (active) mpich-default @3.1.3_0+gcc49 mpich-default @3.1.4_0+gcc49 openmpi-default @1.7.5_3+gcc49 (active) openmpi-default @1.7.5_4+gcc49 openmpi-gcc49 @1.7.5_3+fortran (active) openmpi-gcc49 @1.7.5_4+fortran I am also using the macports hdf5 patched: port installed | grep hdf5 hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.15-patch1_0+cxx+fortran+gfortran (active) Can I get some further help on resolving this? I have not updated macports in a few weeks as I did not want to possibly pollute what did work a while back. Thanks. Comer

4 9

Meeting Minutes for 2015-07-06
by Roland Haas 06 Jul '15

06 Jul '15

Hello all, Present were: Christine, Yosef, Roland Meeting ended early due to lack of quorum. Yours, Roland

2 1

Visualizing data from Carpet
by Soham Mukherjee 02 Jul '15

02 Jul '15

Hi I have been trying to visualize the output from CarpetIOHDF5 in Python, as I want direct control over the data. I reckon, that the CarpetIOHDF5 thorn outputs the grid values for every processor in a separate .h5 file, since none of the files in a database seem to have as many grid points as it should have, and the number of such files exactly match the number of processors engaged in the job. If so, how can I stitch up the outputs from separate processors to get the values on all the grid points for an entire slice? The HDF5 files do contain a dataset named ‘Data Structure’, but I haven’t been yet able to figure out what its output is. If you could kindly help me with it. Thank you Soham

2 1

Meeting Minutes
by Steven R. Brandt 29 Jun '15

29 Jun '15

Hello all, Present were: Steve, Elo, and Matt Tickets: 1667 include elliptic solver: * The discussion seems to have converged on putting the thorn into Numerical or Utils. Are there any objections? Is there any preference for Numerical vs. Utils? I will be unable to host the call next week, as I will be teaching a camp at CCT. Considering that no one is available from LSU for next week, perhaps we should take that week off. Cheers, Steve

3 2

Accuracy issue of multipole moment calculations in QuasiLocalMeasures
by Hee Il Kim 26 Jun '15

26 Jun '15

Hi, Recently, I found the multipole moment calculations in QuasiLocalMeasures show large errors, e.g. 20% for the second mass moment of my project. The error exists even in the test data of the thorn but it's around a few percent. But it couldn't be improved even with increased resolution. From a rough investigation, I found this is because the one in coordinate construction which was supposed to be equal to cos(theta) for a stationary black hole deviates a bit, making erroneous value. I didn't go further. I'd like to know your opinion or any experiences on this. Cheers, Hee Il p.s. I haven't checked whether there's an update of the thorn in the latest version of ET.

3 4

Checking for strdup
by Michael Clark 26 Jun '15

26 Jun '15

With intel-13.2.146 compiler, I've observed that the configure check for strdup (lib/make/configure.in line 494, using CCTK_CHECK_HAS_PROTOTYPE) can fail despite strdup being defined in string.h. The test for this seems to rely on compilation of "int strdup()" failing if this prototype exists, but on a machine I'm using currently, the intel compiler only generates a *warning*, not an *error*, and considers compilation to have "succeeded." Since compilation "succeeded", the test fails, even though strdup's prototype is available. This can be worked around by adding -diag-error 147 (the id code for this diagnostic) to CFLAGS. Is this what end-users should be expected to do? -Michael Clark

2 1

Meeting Minutes for 2015-06-22
by Roland Haas 24 Jun '15

24 Jun '15

Hello all, Present were: Peter, Steve, Christine, Ian, Elo, Matt, Roland Tickets: 1667 include elliptic solver: * several options present themselves (1) use CactusEllitpic (2) use new arrangement Elliptic (3) use a arrangement collecting the author's thorns (4) postpone the decision * Roland objects to adding the solver to CactusElliptic since it is explicitly tied to Carpet and Carpet is not part of Cactus * a general issue exists in that we either have CactusXXX arrangements or EinsteinXXX arrangements but no neutral XXX arrangement ET workshop: There will be an update email to the mailing list with instructions concerning on how to ask for time for a regular talk and how to sign up for lightning talks. Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users