Jupyter strategy

[cvillagrasa]

Hey @Moult @aothms just saw this repo, what are you up to?

Would you want anything from https://github.com/cvillagrasa/IfcOpenHouse to be taken here? I'm not sure about how many time I can allocate for this during the following months, but I feel like 90% of something is already there, so it's a shame it's just getting dust.

@Moult do you think you'll be able to shed some light to the questions I made in the forum?

@aothms do you still want to give a shot to the immutable dicts idea, or the audit hook solution can be acceptable? If we can test the latter enough, it'd be perfect because it just works without the user having to do anything. And code could just be copy-pasted from notebooks to production scripts (or use nbdev to get the script).

A third option could be to declare a custom __setattr__ in some class to deal with overwriting, and then hang every entity instance variable in the notebook as an attribute of an instance of that class... but it's super ugly.

[aothms]

@cvillagrasa sorry I remember discussing something like immutable data in a notebook environment so that you don't accumulate a ton of instances. But I don't remember the details. For me everything is acceptable :) It would make sense that we implement the inverse of ifcopenshell.entity_instance.get_info() to populate a file from a hierarchical json input. And convert back and forth on the fly. But I don't have much time to spare the coming weeks.

[Moult]

I was attempting to use this with binderhub but without any success (binderhub kept timing out - they had resource issues). More than happy for you to go ahead and do whatever it takes to setup a nice Jupyter environment (and then document it for other users here https://blenderbim.org/docs-python/ifcopenshell-python/installation.html#google-colab ) - I know almost nothing about Jupyter.

Sorry I have been meaning to get around to the questions.

1. Agree, just been frying other fish
2. Assign declaration to the project is necessary for IFC project libraries
3. Not a big deal, maybe people might be more comfortable with add_subcontext but it seems like a minor issue
4. Yeah, that might be a nice option
5. This is starting to happen. There is add_profile_representation, and I think we should add shortcuts to other common shapes.
6. Yes. and 6b. Yes.
7. No support yet.
8. Not sure.
9. I believe usages must be used with types.
10. On the todo list.

[cvillagrasa]

Thanks for the answer @aothms . I really don't understand what you meant 100%, so if on top of that it requires your action on the cpp side to get that inverse, and you are OK with the pythonic approaches... I guess we can try them, I'll try the notebook I built in Google Colab ;)

So just to explain how it works, if a simple cell like the following is run:

wall = ios.root.create_entity(file, ifc_class='IfcWall')
ios.spatial.assign_container(file, product=wall, relating_structure=storey);

From the second time on, by the magic of an audit hook, ifcopenshell.util.element.remove_deep2 will be called, the IfcRelContainedInSpatialStructure and IfcWall existing entities will be deleted, wall variable in globals will be assigned to None, and only then the cell content will be executed for the second time.

Hence, the cell can be executed over and over again, and the file won't keep growing orphan entites. Only the step #ID and GlobalId will differ in practice.

The audit hook is triggered when a variable is about to be overwritten and that variable happens to be an ifcopenshell.entity_instance.

@Moult a million thanks for the answers!

I know, there were from very simple questions, to more fundamental ones, to IFC doubts, all mixed in, but it's really what I got from using ifcopenshell in a notebook. I'll further develop some of them in its place. I might tackle the easy 4 also.

Regarding 3, it's not a big deal indeed, but it's still a breaking change (I know, we are alpha stage, but yet). I believe contexts in IFC are already quite difficult for those in AEC who may choose to start coding and use ifcopenshell-python, to also have API calls that can make them confuse contexts with subcontexts. Maybe I'm being too picky but this one I'd really change it.

And regarding 1 / IfcOpenShell/IfcOpenShell#2693... other than to actually redesign the API, what do you guys think of what the officially prescribed alias should be? As in import numpy as np or import pandas as pd, which no one attempts to question. I like maybe import ifcopenshell.api as ios ;)

[cvillagrasa]

The audit thing works OK in Google Colab:
https://colab.research.google.com/drive/1OSYlwfpLhk0-BHBYT0aCuBRilcIt0jQ7?usp=sharing

On the first try, pythonocc-core for the tesselated terrain and the JavaScript callback for the IFC.js viz don't work. I'll investigate and fix.

[cvillagrasa]

With respect to vanilla Jupyter Notebook, Colab is a bit nit-picky for JS <-> Python comms, but got viz working ;)

The above image corresponds to the BSpline terrain. As for the tesselated method, I'm having some type error with the deflection in ifcopenshell.geom.tesselate, which for some reason doesn't happen in my local env.

[Moult]

Very cool! Would you like to submit a PR / have commit access to upgrade this Jupyter stuff?

[cvillagrasa]

Sure! there's still some work to do here, though.

I feel like this repo should have an ipynb (to then be imported from the GitHub ribbon at Colab, and linked in the docs). Or perhaps three: one with a simple wall, one which opens a complete model (as it is now in the docs), and maybe the IfcOpenHouse one, which builds a small model from scratch, but is longer.

Besides, with the IFC.js viz solution I'm using, JS files could either be here or on some external repo (such as my fork of IfcOpenHouse). Note that I added some custom code to render transparent styles, which for some reason weren't working by default, as well as the little menu on double click and so on.

Also, in order to avoid a bunch of wizardry cells in the notebook, maybe it's worth to package something at PyPI, such as then it's as easy as doing !pip install ifcopenshell-colab, import ifcopenshell-colab, and ifcopenshell-colab.init() or alike. That would download the bundles from the corresponding repo and the wasms, which Colab requires to be stored within the environment. Thoughts on something like that? Maybe it's just preferrable to have the wizardry cells under a dropdown.

I also re-read IfcOpenShell/IfcOpenShell#3579 (comment), and something like mybinder.org definitely looks cool! but if you already found that using pip could be difficult, it should be with conda. Why don't you like conda? speed? BTW, in order to have ifcopenshell v7, @jakob-beetz repo could just add the conda ifcopenshell channel before conda-forge, as in here, but maybe it's best to have something more stable on academic repos.

Lastly, the option in https://github.com/IfcOpenShell/wasm-preview/blob/master/index.html is outstanding, but only within the reach of Thomas sorcery. It's fun to see a JavaScript ifcopenshell interacting with three.js, though! ;)

I'll keep updating the progress. Maybe I tackle a PR for q4 above (relaxing the use of matrixes in ifcopenshell.util) before, since it's more important for my use-cases at the moment.

[cvillagrasa]

Minimal example with a simple wall:

https://colab.research.google.com/drive/17XVJJCN6xLKxJR25hBf2Y2vfeW3ybcal?usp=sharing

[cvillagrasa]

Although the example above works, it's kind of odd now that web-ifc-viewer has been suddenly deprecated, with its documentation site down, and with the alternative lib having its docs behind a registration wall.

So I tried to achieve it with xeokit, and I like the result even more! ;)

2023-10-19.10-14-53.mp4

Link to super-easy Colab:
https://colab.research.google.com/drive/1ieceyxgaG5bY7ODoGxBAMaBlx1yLRRnN?usp=sharing

[...] maybe it's worth to package something at PyPI, such as then it's as easy as doing !pip install ifcopenshell-colab, import ifcopenshell-colab, and ifcopenshell-colab.init() or alike.

Do you guys see something like this on this repo, based on the notebook above?

[Moult]

I think this is awesome and personally happy for you to go ahead and do whatever you think necessary :)

[cvillagrasa]

Cool!

Very cool! Would you like to submit a PR / have commit access to upgrade this Jupyter stuff?

Can you grant me commit access?

What I'd do from now on is the following:

1. Maybe change the repo name to ifcopenshell-jupyter? to not only refer to mybinder.org, but also local Jupyter Notebook / Jupyter Lab, or Google Colab. There's also ifcopenshell-jupyterhub, but I'd keep that one separate if universities are using it (maybe it can even benefit from what comes out from here when stable).
2. Define the license. Dumb question: if xeokit is AGPL, all the repo needs to be AGPL, or only the JS scripts? If the latter, do we set the Python part to LGPL to match IfcOpenShell?
3. Move the relevant code from the above notebook to this repo, both Python side and JS/css side
4. Investigate the PyPI thing and end up with a simple package containing the Python boilerplate, which in turn will contain references to the jsdelivr CDN for this repo, for the needed JS.
5. More long term / when I have time, set up all Jupyters to work other than Google Colab.

Ping also @aothms specially on points 1 and 2.