Rust support

[TanJunKiat]

With the rise of the Rust Programming Language, is it possible for a native Rust IfcOpenShell API?

[Tsovak]

thump up this for adding support for Rust

[aothms]

100% in favour, but it's not going to come from me given limited time and experience with rust. We're always open to contributions :)

[gnuion]

Memory leakage issues are of big concern and could crash the app/library. The memory-safe feature of Rust makes the language a good fit for this project. I suggest we fork the project and rewrite it in Rust. If it is a success, we can move to the new library. I can only volunteer a few hours a week. So we will need human resources because AI can't do it by itself yet.

[aothms]

Maybe a better starting point would be to talk to guys at https://github.com/stepcode/stepcode. They have a narrower scope because they don't need to interface with the C++ geometry libraries. If that's a success we can swap out the C++ parser module in ifcopenshell with your rust port. That would also enable to most use of your effort because it can be more generally applied.

For me, highest priority would be reducing indirections and memory overhead. Currently in IfcOpenShell we have, at the parser level, object storage using inheritance and virtual methods. On top of that a schema layer is applied that coerces the tokens according to the schema. This is inefficient, because we have generic storage, but can only access the data through the typed layer that needs to do coercion. It would be interesting if the parser can already be informed on the structure of the entity so that it can at parse time already store the data in an efficiently packed tuple without indirections or virtual calls. The schema language (EXPRESS) doesn't support aggregates with non-uniform elements, so the type information does not need to be stored for every element, which we currently also do.

If we can get:

• A more efficient parser+storage
• Potentially offload to disk / memory mapping in high memory situations
• A modern API (also conveniently accessed from c/c++)
• Compilation to various backends such as wasm
• Memory safety

I'm sure people in the community will be eager to adopt it and contribute. I think rust also has some pretty good parser libraries. The P21 grammar that is used for the .ifc files is rather elegant.

[Krande]

Hey, I came across https://github.com/ricosjp/ruststep and think it might be relevant for this discussion.

They're building a rust cad kernel "truck" (see https://github.com/ricosjp/truck).

I havent tried it myself, but if anyone of you are keen on learning rust, this could be a way in?

[TanJunKiat]

Hmmm interesting.

Right now I am trying to create the IFC Openshell library in Rust, but am struggling to parse the IFC lines. I will look into using ruststep as suggested. Thanks @Krande

But most importantly, failing to find a suitable method to return the IFC element via get_by_id() because Rust does not allow function overloading like c++.

Looking at how we can better do the latter.

Any feedback or suggestion will be appreciated.

Update

Yes, it seems like ruststep is looking to parsing the IFC file and storing them in structs there. If that is possible, it will definitely be helpful for the ifcopenshell_rust development.

[civilx64]

Chiming in to register my interest as well.

Potentially offload to disk / memory mapping in high memory situations

such as deserializing face sets directly to USD prims?

I see two primary components:

• STEP parser
• Rust code generation from express schema

logos or nom are potential lower-level options for the first part. Ruststep appears to use nom so perhaps that component is already in hand.

Stepcode seems to be as the logical tool for the second part.

@TanJunKiat do you have a repo started already? Is ruststep complete enough to handle the parsing step?

[TanJunKiat]

@civilx64

Sorry but I haven't gotten the time to look in-depth into ruststep at the moment. I am trying to work on the Ifcopenshell-rust independently without other critical rust libraries to see if it is possible.

And yes, I have started a repository to test some concepts.

I will open the repository once I get it to the point that I think it's ready, hopefully some time around this month.

The current methodology that I am using is summarized as such:

Trait on IFC entities

All entities will be given a IfcDataOps trait that contains typical functions like parsing and getting ids. This also allows the model struct to contain a dynamic trait hashmap to store all the data.

Manual parsing

Right now the parsing of the data is pretty manual, with slicing and getting each element and storing them in the respective structs. Definitely would be helpful if we can have a dedicated serialiser/desarialiser for our purpose.

---

The biggest challenge right now for me is handling the large volume of IFC entities that needs to be programmed (e.g. to parse) and still figuring out the best way to approach the crate in general (e.g. proper use of traits, generics).

I will definitely be happy for the community to come together to do this together. With my limited knowledge on Rust and limited time to work on this, any help and advice is much appreciated.

[civilx64]

Sorry but I haven't gotten the time to look in-depth into ruststep at the moment.

No problem and no need to apologize! I was just wanting to document current status for the benefit of the community to minimize duplication of effort.

The biggest challenge right now for me is handling the large volume of IFC entities that needs to be programmed...

Indeed, generating the code for rust structs for all entities across multiple schema versions is near-impossible to do by hand. Some combination of stepcode and potentially LLM seems to be a promising option. In the meantime you might consider writing a generic EntityInstance struct that holds the IFC type as an attribute - similar to how things are exposed in the python wrapper.

With my limited knowledge on Rust and limited time to work on this...

I think this goes for most of us 😃.

[TanJunKiat]

Indeed, generating the code for rust structs for all entities across multiple schema versions is near-impossible to do by hand. Some combination of stepcode and potentially LLM seems to be a promising option. In the meantime you might consider writing a generic EntityInstance struct that holds the IFC type as an attribute - similar to how things are exposed in the python wrapper.

Yea, while tedious, I do find some incentive of writing the structs manually. Like embbed test cases for the differrent entities as well as documentation from web directly into the codebase.

We can definitely discuss and see what is the direction the community wants to go for.

[TanJunKiat]

Another note is that since we are writing the library in Rust, it might be worthwhile to gather feedback on what are the common issues in the existing libraries and see if we can solve them with the rust version.

[aothms]

In the meantime you might consider writing a generic EntityInstance struct that holds the IFC type as an attribute - similar to how things are exposed in the python wrapper.

Yes, this is the main design decision to make. In IfcOpenShell we have the schema types and data storage as separate things. I've recently rewrote quite some stuff. Data storage is a custom type called VariantArray. https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.8.0/src/ifcparse/variantarray.h On top of the schema classes index into this array as functions with a return type. I imagined this would be best of both worlds: not too many code paths in the parser module and still type safety by means of the schema layer (that could potentially be inlined). This also allows to store invalid data types which we actually need for our validator.

[TanJunKiat]

Right now this is the approach that I am adopting for storing the entities, using just IfcDirection as example but can be applied for all entities.

Instead of a generic struct, I'm defining the data as a HashMap with the data index as the key and a Box<dyn trait> as the value. This allows us to store any kind of Struct that has this trait.

use log::debug;
use std::collections::HashMap;

#[derive(Debug, PartialEq, Eq, Clone)]
pub struct ParseError;

pub trait IfcDataOps {
    fn parse(s: &str) -> Result<Self, ParseError>
    where
        Self: Sized;
}

#[derive(Default)]
pub struct Model {
    data: HashMap<usize, Box<dyn IfcDataOps>>,
}

impl Model {
    pub fn open(file_path: &str) -> Model {
        let mut model = Model {
            data: HashMap::new(),
        };

        let contents = std::fs::read_to_string(file_path)
            .expect(format!("File path, {}, not available.", file_path).as_str());

        let lines: Vec<&str> = contents.split("\n").collect();

        for line in lines.iter() {
            if line.contains("=IFCDIRECTION(") {
                if let Ok(direction) = IfcDirection::parse(line) {
                    debug!("Parsed {:?}", direction);
                    model.data.insert(direction.id, Box::new(direction));
                }
            }
        }

        return model;
    }
}

#[derive(Debug)]
pub struct IfcDirection {
    id: usize,
    x: f32,
    y: f32,
    z: Option<f32>,
}

impl IfcDataOps for IfcDirection {
    fn parse(s: &str) -> Result<Self, ParseError> {
        let id = s[1..s.find("=").unwrap_or(s.len())]
            .parse::<usize>()
            .unwrap();

        let s = &s[s.find("((").unwrap_or(s.len()) + 2..s.len()];
        let s = &s[0..s.find("));").unwrap_or(s.len())];
        let mut coordinates = Vec::new();
        for (_, value) in s.split(",").enumerate() {
            coordinates.push(value.parse::<f32>().unwrap());
        }
        if coordinates.len() == 2 {
            return Ok(IfcDirection {
                id,
                x: coordinates[0],
                y: coordinates[1],
                z: None,
            });
        } else {
            return Ok(IfcDirection {
                id,
                x: coordinates[0],
                y: coordinates[1],
                z: Some(coordinates[2]),
            });
        }
    }
}

While programming, I want to make good use of some of the functions in Rust, such as using Option<> to define optional attributes and clever use of Results<> to control the workflow.