April 2015 - moab-dev - mailman3.cels.anl.gov

Polyhedra elements in parallell
by WARNER, JAMES E. (LARC-D309) 01 May '15

01 May '15

Hello, I generated a MOAB finite element mesh with polyhedra elements that works fine on one processor. However, when I use mbpart to generate two partitions and run my finite element code in parallel, I get the following error when calling DMMoabLoadFromFile() : " ParallelComm.cpp:2928: moab::ErrorCode moab::ParallelComm::get_local_handles(moab::EntityHandle*, int, const std::vector<long unsigned int>&): Assertion `ID_FROM_HANDLE(from_vec[i]) < (int) new_ents.size()' failed. " Ultimately, I'd like to use MOAB's polyhedra elements to implement arbitrary user-defined finite elements in the code I work on, but as a simple initial test I am trying to create a mesh with just two 3D bricks using MBPOLYHEDRON rather than MBHEX. I first generate 2D quad elements for the six facets of each 3D element and use an array of these facets as the connectivity for each polyhedron element, according to the documentation. I don't get any warning or error messages when generating the input mesh file or when calling mbpart to partition the mesh, only when trying to read it into the finite element code in parallel. And again, it appears to be working correctly in serial. It's possible I am overlooking something in my code for generating the mesh, so if you can provide any info about the error above and what may be causing it I'd appreciate it! Thanks a lot, -Jim

3 9

Re: [MOAB-dev] [Nek5000-users] MOAB Cubit problem
by Rajeev Jain 29 Apr '15

29 Apr '15

If the mesh file is not too large, please send us the mesh file that breaks mbconvert. Thanks. Rajeev Jain 630-252-3176 / 630-252-5986 (fax) jain(a)mcs.anl.gov From: Vijay S. Mahadevan <vijay.m(a)gmail.com> To: nek5000-users <nek5000-users(a)lists.mcs.anl.gov>; "moab-dev(a)mcs.anl.gov" <moab-dev(a)mcs.anl.gov> Sent: Wednesday, April 29, 2015 1:23 PM Subject: Re: [MOAB-dev] [Nek5000-users] MOAB Cubit problem Hamid, It is possible that the file formats are quite different between Cubit and Trelis. We have not tested with the Trelis versions so far and do plan to acquire a license to make these conversions possible. Meanwhile, if you want to use Exodus or any other format that MOAB can understand directly, that would simplify your workflow. We will keep you updated about the progress, if you're interested. Vijay On Wed, Apr 29, 2015 at 11:47 AM, <nek5000-users(a)lists.mcs.anl.gov> wrote: > Hi, > I use Trelis (V 15) to generate mesh. However, when I try to use mbconvert > to generate h5m file, it says > > [0]MOAB ERROR: --------------------- Error Message > ------------------------------------ > [0]MOAB ERROR: This doesn't appear to be a .cub file! > [0]MOAB ERROR: load_file() line 310 in src/io/Tqdcfr.cpp > [0]MOAB ERROR: --------------------- Error Message > ------------------------------------ > [0]MOAB ERROR: Failed to load file after trying all possible readers! > [0]MOAB ERROR: serial_load_file() line 634 in src/Core.cpp > [0]MOAB ERROR: load_file() line 523 in src/Core.cpp > Failed to load "/home/hamid/nek5_svn/moab_conjht/cubit01.cub". > Error code: MB_FAILURE (16) > Error message: Failed to load file after trying all possible readers > > I have downloaded other cub files from repository and mbconvert works fine > on them. > However opening and saving these files with Trelis causes same problem. > I think the file format in Trelis is different than Cubit. Is it true? if > yes what is the solution? > > Hamid > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users(a)lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >

1 0

Re: [MOAB-dev] [Nek5000-users] MOAB Cubit problem
by Vijay S. Mahadevan 29 Apr '15

29 Apr '15

Hamid, It is possible that the file formats are quite different between Cubit and Trelis. We have not tested with the Trelis versions so far and do plan to acquire a license to make these conversions possible. Meanwhile, if you want to use Exodus or any other format that MOAB can understand directly, that would simplify your workflow. We will keep you updated about the progress, if you're interested. Vijay On Wed, Apr 29, 2015 at 11:47 AM, <nek5000-users(a)lists.mcs.anl.gov> wrote: > Hi, > I use Trelis (V 15) to generate mesh. However, when I try to use mbconvert > to generate h5m file, it says > > [0]MOAB ERROR: --------------------- Error Message > ------------------------------------ > [0]MOAB ERROR: This doesn't appear to be a .cub file! > [0]MOAB ERROR: load_file() line 310 in src/io/Tqdcfr.cpp > [0]MOAB ERROR: --------------------- Error Message > ------------------------------------ > [0]MOAB ERROR: Failed to load file after trying all possible readers! > [0]MOAB ERROR: serial_load_file() line 634 in src/Core.cpp > [0]MOAB ERROR: load_file() line 523 in src/Core.cpp > Failed to load "/home/hamid/nek5_svn/moab_conjht/cubit01.cub". > Error code: MB_FAILURE (16) > Error message: Failed to load file after trying all possible readers > > I have downloaded other cub files from repository and mbconvert works fine > on them. > However opening and saving these files with Trelis causes same problem. > I think the file format in Trelis is different than Cubit. Is it true? if > yes what is the solution? > > Hamid > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users(a)lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >

1 0

Re: [MOAB-dev] Polyhedra elements in parallell
by Rajeev Jain 27 Apr '15

27 Apr '15

Can you send your mesh file? Rajeev Jain 630-252-3176 / 630-252-5986 (fax) jain(a)mcs.anl.gov From: "WARNER, JAMES E. (LARC-D309)" <james.e.warner(a)nasa.gov> To: "moab-dev(a)mcs.anl.gov" <moab-dev(a)mcs.anl.gov> Sent: Monday, April 27, 2015 3:12 PM Subject: [MOAB-dev] Polyhedra elements in parallell Hello, I generated a MOAB finite element mesh with polyhedra elements that works fine on one processor. However, when I use mbpart to generate two partitions and run my finite element code in parallel, I get the following error when calling DMMoabLoadFromFile() : "ParallelComm.cpp:2928: moab::ErrorCode moab::ParallelComm::get_local_handles(moab::EntityHandle*, int, const std::vector<long unsigned int>&): Assertion `ID_FROM_HANDLE(from_vec[i]) < (int) new_ents.size()' failed." Ultimately, I'd like to use MOAB's polyhedra elements to implement arbitrary user-defined finite elements in the code I work on, but as a simple initial test I am trying to create a mesh with just two 3D bricks using MBPOLYHEDRON rather than MBHEX. I first generate 2D quad elements for the six facets of each 3D element and use an array of these facets as the connectivity for each polyhedron element, according to the documentation. I don't get any warning or error messages when generating the input mesh file or when calling mbpart to partition the mesh, only when trying to read it into the finite element code in parallel. And again, it appears to be working correctly in serial. It's possible I am overlooking something in my code for generating the mesh, so if you can provide any info about the error above and what may be causing it I'd appreciate it! Thanks a lot,-Jim

1 0

mbconvert from abaqus to h5m
by Jacob Hochhalter 27 Apr '15

27 Apr '15

Hello, I would like to use the mbconvert tool to translate abaqus '.inp' files to '.h5m' files. I have tried the following command: mbconvert -g tet4.inp tet4.h5m on moab 4.6 and 4.8 (tet4.inp is attached), but both return '.h5m' files without any mesh data. 'mbconvert -l' returns: Format Description Read Write File Name Suffixes ------ ----------------------------- ---- ----- ------------------ ... Abaqus mesh ABAQUS INP mesh format yes no abq ... which makes me think I should be able to run the conversion. Am I missing something, or is this not yet functional? Thanks, - Jake

3 6

Moab with Visual Studio
by Steve Balderrama 13 Apr '15

13 Apr '15

Is anyone currently building Moab with Visual Studio compilers? I'd like some help with the process if so, thanks. ___________________________________________________ Steve Balderrama Technical Lead, IMS - Engineering Design Applications American Bureau of Shipping (ABS) 16855 Northchase Dr., Houston, TX, 77060 Email: sbalderrama(a)eagle.org<mailto:[email protected]> | Telephone 281-877-5981

2 1

Re: [MOAB-dev] Converting to .h5m from Fluent .msh
by Paul Wilson 13 Apr '15

13 Apr '15

Hi Anton, I don't believe that such an option exists. The cells are defined based on canonical ordering of the nodes, so this relationship is important. I might not be hard to write a method that would do this for your purposes. There may be something useful in the ReadCCMIO reader as well, as Tim suggested. Paul On 04/10/2015 04:13 PM, Kanaev A.A. wrote: > Hello Paul, > > Thanks for the recommendations! > > Short question: is there an option in MOAB to create cells from faces, not from nodes? > > Anton > ________________________________________ > From: Paul Wilson [paul.wilson(a)wisc.edu] > Sent: Thursday, April 09, 2015 5:12 PM > To: Kanaev A.A. > Subject: Re: [MOAB-dev] Converting to .h5m from Fluent .msh > > Hello Anton, > > There are a number of mesh format readers in moab/src/io that might > provide a good template. I know of a few different formats that have > had features implemented on an as-needed basis, so they are not > complete, but provide just enough for what the person needed at the > time. For example, I'll take the credit/blame for the ABAQUS reader > that only supports a subset of the element types that ABAQUS can generate. > > Many of the mesh files have very similar formats, so it might make sense > to take a look at other readers to see which is the best match to use as > a starting point and/or guide. > > Paul > > On 04/08/2015 06:44 PM, Kanaev A.A. wrote: >> Hello MOAB-dev, >> I'm considering writing conversion utility from Fluent .msh to MOAB .h5m >> >> .msh format is: >> -nodes declaration >> - a list of nodes (x, y, z) >> -cells declaration >> -faces declaration >> - a list of faces (node1, node2, node3, node4, adj cell1, adj cell2) >> >> What should i do next to create mesh from scratch with MOAB? >> >> Thanks, >> Anton > -- > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- > Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://go.wisc.edu/pphw-cal > Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu > Faculty Director, Advanced Computing Infrastructure ~ http://aci.wisc.edu > -- -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ -- Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: http://go.wisc.edu/pphw-cal Professor, Engineering Physics. ~ http://cnerg.engr.wisc.edu Faculty Director, Advanced Computing Infrastructure ~ http://aci.wisc.edu

2 1

Converting to .h5m from Fluent .msh
by Kanaev A.A. 09 Apr '15

09 Apr '15

Hello MOAB-dev, I'm considering writing conversion utility from Fluent .msh to MOAB .h5m .msh format is: -nodes declaration - a list of nodes (x, y, z) -cells declaration -faces declaration - a list of faces (node1, node2, node3, node4, adj cell1, adj cell2) What should i do next to create mesh from scratch with MOAB? Thanks, Anton

2 1

Re: [MOAB-dev] synchronisation of ranges
by Lukasz Kaczmarczyk 02 Apr '15

02 Apr '15

Hello Vijay, I need one clarification, under what condition entities are PSTATUS_MULTISHARED, I have a case that I think entity should be multi-shared, but it is only PSTATUS_SHARED. Can you explain at one condition entity is MULTISHARED. Kind regards, Lukasz > On 1 Apr 2015, at 23:15, Lukasz Kaczmarczyk <Lukasz.Kaczmarczyk(a)glasgow.ac.uk> wrote: > > >> On 1 Apr 2015, at 22:52, Vijay S. Mahadevan <vijay.m(a)gmail.com> wrote: >> >> I think I understand your use case a little better now but there are >> still points of confusion. >> >>> Proc 0 Range { 1,2,3,4,6 (shared) } >>> Proc 1 Range { 7,8,9, 10 (shared) } >>> >>> After synchronisation, >>> >>> Proc 0 Range { 1,2,3,4,6,10 } >>> Proc 1 Range { 6,7,8,9,10 } >> >> Are these entity handles in each of the processors or are you storing >> the GLOBAL_ID corresponding to the entity handles here ? If you are >> storing the entity_handles directly, then you could decipher the local >> id of the handle which usually start from 1 on each processor. > > Those are not IDs, I have in mind entity handles. > >> >> The reason I ask is because you cannot directly use a Range here since >> locally only EntityHandle 6 is defined in proc_0 and 10 is defined on >> proc_1. EntityHandle=10 does not exist in proc_0 since the handle is >> not associated with a vertex. If however, you probe at the remote >> handle of the shared entity, then you could decipher that on proc_1, >> the local entity 10 (that is shared) corresponds to the local handle >> on proc_0 as 6. > > Yes, I am aware of this., I exchange owner entity handles, to avoid this problem. > >> >> Part of the mis-communication here is also how MOAB looks at >> shared/ghosted vs how PETSc defines ghosted components. I had to go >> through similar mapping issues when writing the DMMoab interface in >> PETSc. > > In principle I do all communication using PETSc, that way I follow that problem. In my case I have some additional complexities related to different approximation spaces. I keep in tags global, petsc local and petsc global indices. On each entity I can have many tages, related to difftent approx. spaces, fields or ranks. If I have synchronised ranges, all communication from that point can be done by petsc vectors. > > I have to schemes, mesh on all processor and parallel algebra. And parallel mesh and parallel algebra. Now I make some improvements in second one, that why is this problem. > >> >>> Such that exist global range { 1,2,3,4,6,7,8,9,10 } distributed on two processors, where entities 6 and 10 are shared. With that at hand I can do some operations on this global range. I do not have to exchange values on tags each time I updated tags. Some times I can calculate those values or those are set from ghosted petsc vector. Using tag exchange I will need to have additional avoidable communication. >> >> Back to the problem at hand: you could choose to filter out only the >> shared vertices and call pcomm->get_remote_handles [1] to create a >> global list of entities on which you want to set tag data. Please be >> careful to not call exchange/reduce tags or any functions in >> ParallelComm that might call exchange_tags internally since it might >> overwrite the data that you explicitly might set on the shared >> entities. > > That could be very useful. I overlooked this. Thanks. > > Lukasz > >> >> Vijay >> >> [1] http://ftp.mcs.anl.gov/pub/fathom/moab-docs/classmoab_1_1ParallelComm.html#… >> >> On Wed, Apr 1, 2015 at 4:26 PM, Lukasz Kaczmarczyk >> <Lukasz.Kaczmarczyk(a)glasgow.ac.uk> wrote: >>> Hello, >>> >>> Yes, in some sense is similar. >>> >>> However, I do not want to exchange tags, I like to set some values to tags (not necessary the same values on each processor) on some entities collectively. As an input I have some range of entities on each processor, however I don;t know if it is complete. >>> >>> >>> Proc 0 Range { 1,2,3,4,6 (shared) } >>> Proc 1 Range { 7,8,9, 10 (shared) } >>> >>> After synchronisation, >>> >>> Proc 0 Range { 1,2,3,4,6,10 } >>> Proc 1 Range { 6,7,8,9,10 } >>> >>> Such that exist global range { 1,2,3,4,6,7,8,9,10 } distributed on two processors, where entities 6 and 10 are shared. With that at hand I can do some operations on this global range. I do not have to exchange values on tags each time I updated tags. Some times I can calculate those values or those are set from ghosted petsc vector. Using tag exchange I will need to have additional avoidable communication. >>> >>> Regards, >>> L. >>> >>> >>> >>>> On 1 Apr 2015, at 22:06, Vijay S. Mahadevan <vijay.m(a)gmail.com> wrote: >>>> >>>> This functionality looks quite similar to what exchange_tags routine >>>> provides on ParallelComm. Have you tried this to synchronize the tag >>>> data already ? >>>> >>>> http://ftp.mcs.anl.gov/pub/fathom/moab-docs/classmoab_1_1ParallelComm.html#… >>>> >>>> I'll look over the function you implemented again to better understand >>>> your use-case if exchange_tags doesn't solve the issue. >>>> >>>> Vijay >>>> >>>> >>>> >>>> On Wed, Apr 1, 2015 at 3:15 PM, Lukasz Kaczmarczyk >>>> <Lukasz.Kaczmarczyk(a)glasgow.ac.uk> wrote: >>>>> Hello Vijay, >>>>> >>>>> Yes, this is first step, next one is to synchronise entities in ranges between processors. >>>>> >>>>> Imagine that you partitioned tetrahedral, then you take subset of those tetrahedrals (on each part), and next you take adjacencies, f.e. faces of those tetrahedral. On each processor you need to do collectively set data on tags of those faces. On some processors you can any tetrahedral which is part of the subset, but you can have some faces which are on skin of that subset. In such a case you need synchronise such entities in the range. >>>>> >>>>> I already made some eclectic implementation of this, see line, >>>>> 491 PetscErrorCode Core::synchronise_entities(Range &ents,int verb) { >>>>> >>>>> in >>>>> http://userweb.eng.gla.ac.uk/lukasz.kaczmarczyk/MoFem/html/_core_8cpp_sourc… >>>>> >>>>> It looks that it working, but not tested properly. >>>>> >>>>> Kind regards, >>>>> Lukasz >>>>> >>>>> >>>>>> On 1 Apr 2015, at 20:30, Vijay S. Mahadevan <vijay.m(a)gmail.com> wrote: >>>>>> >>>>>> Lukasz, >>>>>> >>>>>> The Range data-structure stores locally visible data (EntityHandles) >>>>>> only and you can store these from various queries on the Interface >>>>>> class. If you specifically want to store the shared entities in a >>>>>> range, you can apply a Pstatus filter like below: >>>>>> >>>>>> Range vlocal, vowned, vghost, adjs; >>>>>> // Get all local vertices: owned + ghosted (including shared) >>>>>> merr = mbiface->get_entities_by_dimension(0, 0, vlocal, false);MB_CHK_ERR(merr); >>>>>> >>>>>> // filter based on parallel status >>>>>> merr = pcomm->filter_pstatus(vlocal,PSTATUS_NOT_OWNED,PSTATUS_NOT,-1,vowned);MB_CHK_ERR(merr); >>>>>> >>>>>> // filter all the non-owned and shared entities out of the list >>>>>> adjs = moab::subtract(vlocal, vowned); >>>>>> merr = pcomm->filter_pstatus(adjs,PSTATUS_GHOST|PSTATUS_INTERFACE,PSTATUS_OR,-1,&vghost);MB_CHK_ERR(merr); >>>>>> adjs = moab::subtract(adjs, vghost); >>>>>> vlocal = moab::subtract(vlocal, adjs); >>>>>> >>>>>> Instead of PSTATUS_GHOST, you could use PSTATUS_SHARED if you wanted >>>>>> to filter different set of (shared) entities locally. Hope this helps. >>>>>> If not, let us know what is unclear. >>>>>> >>>>>> Vijay >>>>>> >>>>>> On Wed, Apr 1, 2015 at 6:43 AM, Lukasz Kaczmarczyk >>>>>> <Lukasz.Kaczmarczyk(a)glasgow.ac.uk> wrote: >>>>>>> Hello, >>>>>>> >>>>>>> It is quick method to synchronise ranges. >>>>>>> >>>>>>> 1) Range on each processor keeps entities, some of those entities are shared between one or more processors. >>>>>>> >>>>>>> 2) I need collectively synchronise that ranges, such that if entity is in range on one of processors is as well in range on other processors (only if it is shared). >>>>>>> >>>>>>> 3) I do not need to send entity, only synchronise entities in range which are shared. >>>>>>> >>>>>>> This is needed for collective operations on tags, instead of exchanging tags values, I need to synchronise range and then collectively set tags. >>>>>>> >>>>>>> >>>>>>> Kind regards, >>>>>>> Lukasz Kaczmarczyk >>>>>>> >>>>> >>> >

2 1

synchronisation of ranges
by Lukasz Kaczmarczyk 01 Apr '15

01 Apr '15

Hello, It is quick method to synchronise ranges. 1) Range on each processor keeps entities, some of those entities are shared between one or more processors. 2) I need collectively synchronise that ranges, such that if entity is in range on one of processors is as well in range on other processors (only if it is shared). 3) I do not need to send entity, only synchronise entities in range which are shared. This is needed for collective operations on tags, instead of exchanging tags values, I need to synchronise range and then collectively set tags. Kind regards, Lukasz Kaczmarczyk

2 5