Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eavp-dev] Comparison between FENICS and ICE mesh formats

Our format is extremely compact, while theirs is very verbose. For example, here is a line for assigning a boundary condition reference to a face in the FENICS files:


    <value cell_index="421" local_entity="3" value="62" />


We represent this same information by appending the string "62 " to the line in the <Faces> block corresponding to tetrahedron 421's 3rd face. There are nearly two million such boundary condition lines in the original file. 


Note that not all FENICS files have such a large number of boundary conditions, as almost all faces are assigned boundary condition 0 in this file, with very few lacking an assignment at all, while other files I have seen lack boundary conditions assignments for most faces. I think this particular file may be poorly specified (ie they should have made boundary condition 0 the default instead and the default 0, though I'm not sure that's actually possible to do in FENICS.) In any case, other FENICS files will probably not have quite that extreme of space savings. 


Robert

From: eavp-dev-bounces@xxxxxxxxxxx <eavp-dev-bounces@xxxxxxxxxxx> on behalf of Jay Jay Billings <jayjaybillings@xxxxxxxxx>
Sent: Tuesday, June 21, 2016 11:38 AM
To: eavp developer discussions
Subject: Re: [eavp-dev] Comparison between FENICS and ICE mesh formats
 
Okay, good. So why is our file half the size of theirs? Any guesses?

Jay

On Tue, Jun 21, 2016 at 8:48 AM, Smith, Robert W. <smithrw@xxxxxxxx> wrote:

​Jay,


Sorry, that was a typo. It should have read 75,024 KB, not 75.024. 


Robert

From: eavp-dev-bounces@xxxxxxxxxxx <eavp-dev-bounces@xxxxxxxxxxx> on behalf of Jay Jay Billings <jayjaybillings@xxxxxxxxx>
Sent: Monday, June 20, 2016 7:43 PM
To: eavp developer discussions
Subject: Re: [eavp-dev] Comparison between FENICS and ICE mesh formats
 
Robert,

These are very interesting results. Could you clarify the file size after conversion please? Was it 75KB or 75MB? If it was 75KB, down from 150MB, then we need some explanation for the massive compression. If not, then where do we get the factor of two difference in file size?

Great work, btw.

Jay

On Mon, Jun 20, 2016 at 9:46 AM, Smith, Robert W. <smithrw@xxxxxxxx> wrote:

I have experimented with the FENICS file format to test how it compares to the proposed ICE format found here. 


First it must be noted I had to change our format to account for the fact that the sample FENICS file had boundary conditions on the faces instead of the edges. Thus, the following changes were made to the proposed ICE format:


The Edges block was changed to read EdgeID Vertex1 Vertex2 on each line.


The Faces block was changed to read Face ID FieldVariable1 FieldVariable2...;Edge1 Edge2...;BoundaryCondition1 BoundaryCondition2 on each line. Since the FENICS file did not specify field variables, these are simply omitted for our sample. 


A Cells block was added, with the following format:

<Cells>

CellID Face1 Face2...

</Cells>


In reality, it might be more flexible to have a single persisted JaxB object followed by a block of such compressed descriptions. For example:


<Defaults>

    <Tetrahedron id="0" name="Tetrahedron">

<Defaults>


<Cells>

    Tetrahedron

    CellID Face1 Face2

    CellID Face1 Face2

</Cells>


This would allow us to unmartial to an arbitrary class without having to persist the entire <Tetrahedron id=...> node for every individual cell of that type.


Also of note is that FENICS stores boundary condition information in a different file. This means that our ICE file is also missing boundary condition definitions, and both files only contain references to boundary condition IDs. A full description for a problem would involve larger files and longer run times for both formats.


___________________


I ran the test on a 148,970 KB FENICS format file. It took about 11.5-12.5 seconds to parse the file into a set of simple data structures, 5-6.4 seconds of which was spent reading the file in.


After converting to the ICE format, the files was 75.024 KB large. It took about 5-5.5 seconds to parse the file, about .8 seconds of which was spent reading the file in.


The extreme decrease in time is due to the very simple data structures used in the ICE file. When reading the FENICS file, Java will instantiate over a million objects, all of which we read data out of then never use again. By comparison, the ICE file results in only a few objects, and the vast majority of the data is simply held in very large strings. If we were to actually use the data structures constructed by the XML parser, such as by creating JaxB annoted classes that could parse the FENICS file nodes into usable data structures directly, then the two may move closer together as the extra work of reading the file is partially made up for by the fact that there is no additional step in which the text strings are converted into data objects, as is in the ICE file.


Robert Smith


_______________________________________________
eavp-dev mailing list
eavp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eavp-dev




--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings

_______________________________________________
eavp-dev mailing list
eavp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eavp-dev




--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings

Back to the top