# CIF handling should be optimized (I) **URL:** \ **Category:** Support\ **Created:** [January 27, 2026, 5:37pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287 "2026-01-27T17:37:03Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![anon86203829](https://discuss.avogadro.cc/letter_avatar_proxy/v4/letter/a/77aa72/32.png) [@anon86203829](https://discuss.avogadro.cc/u/anon86203829)\ **Post date:** [January 27, 2026, 5:37pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/1 "2026-01-27T17:37:03Z")
Dear all, since the release of Avogadro 2 is imminent, I would like to quickly mention a few things regarding the crystallography functionalities. 1. I think most users would expect that when loading a CIF, the entire unit cell content would be displayed, not just the asymmetric unit as is currently the case. 2. The “Fill unit cell…” command does not work properly, see image of an NaCl crystal. 3. It is unclear to me what the “Wrap Atoms to Unit Cell” command means – perhaps that only atoms with coordinates between 0.001 and 0.999 are displayed? In any case, this command does not work either; only a few bonds are drawn (see image below). 4. The “Plot Theoretical XRD Pattern” command does not work for me (“Could not find genXrdPetern executable”). 5. It would be great if there were a command that displays multiple unit cells without having to automatically build a supercell. I’m using: Avogadro version: 1.102.1 Operating system and version: Win 11 home best wishes Frank ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [January 27, 2026, 6:03pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/2 "2026-01-27T18:03:36Z")
You can find ample discussion of this on the forum (e.g. from @Thomas in particular) . I welcome suggestions.. there are a few requests on the [GitHub issues](https://github.com/OpenChemistry/avogadrolibs/issues) as well. > [@anon86203829](#): > > I think most users would expect that when loading a CIF, the entire unit cell content would be displayed, not just the asymmetric unit as is currently the case. The problem is that some CIF are molecules (i.e., give me just the asymmetric unit) and some are solids, in which case people want the primitive cell. I welcome [heuristics](https://discuss.avogadro.cc/t/heuristic-for-reading-cif-crystal-structures-v2/5340/) to differentiate these use cases. Using the asymmetric unit, with the ability to generate the primitive cell easily is the current default. If you have a good suggestion for “this CIF should show the primitive cell instead of the asymmetric unit” I’d be happy to implement it (e.g. how to detect a molecule vs. a solid) > [@anon86203829](#): > > The “Fill unit cell…” command does not work properly, see image of an NaCl crystal. I’m not sure what you want it to do. That’s the primitive unit cell. Do you want it to include the redundant edge and corner atoms? The catch of course with that is exporting to other formats (e.g., calculations) in which primitive is needed and the edge and corner atoms are duplicates. We can certainly add some command like “Fill Edges and Corners” or something.. Suggestions for wording would be helpful. > [@anon86203829](#): > > It is unclear to me what the “Wrap Atoms to Unit Cell” command means – perhaps that only atoms with coordinates between 0.001 and 0.999 are displayed? It takes any atoms outside of [0, 1] and wraps them into the base unit cell. Perhaps that’s a documentation thing, but I’m not sure why you think that isn’t working? Please don’t take this as critical - I definitely want to see improvements in how we handle crystal structures, solids and materials. > [@anon86203829](#): > > The “Plot Theoretical XRD Pattern” command does not work for me (“Could not find genXrdPetern executable”). Hmm. I’ll see why that’s missing. You should be able to download it from [https://github.com/psavery/genXrdPattern/releases/download/1.0-static/win64-genXrdPattern.exe](https://github.com/psavery/genXrdPattern/releases/download/1.0-static/win64-genXrdPattern.exe) ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [January 27, 2026, 8:15pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/3 "2026-01-27T20:15:52Z")
We’ve talked about the heuristics maybe a few times. At the moment, we don’t do our own CIF parsing, so we don’t have easy access to the `_chemical_formula_moiety` etc. (and sometimes those are missing anyway). But maybe this is “a good start” for a heuristic: - Contains C + H and \>5 atoms → probably molecular - Simple ionic (metal + halide/chalcogenide) → extended - Simple element → extended Those obviously aren’t foolproof, but would help a lot of use cases. As far as the “fill unit cell” not doing what you expect, I’m curious to know what you’d want it to do. ---
**Author:** ![anon86203829](https://discuss.avogadro.cc/letter_avatar_proxy/v4/letter/a/77aa72/32.png) [@anon86203829](https://discuss.avogadro.cc/u/anon86203829)\ **Post date:** [January 27, 2026, 8:42pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/4 "2026-01-27T20:42:30Z")
> [@ghutchis](#): > > The problem is that some CIF are molecules (i.e., give me just the asymmetric unit) and some are solids, in which case people want the primitive cell. Ok, I see. > [@ghutchis](#): > > If you have a good suggestion for “this CIF should show the primitive cell instead of the asymmetric unit” I’d be happy to implement it (e.g. how to detect a molecule vs. a solid) No, no suggestion, sorry. > [@ghutchis](#): > > I’m not sure what you want it to do. That’s the primitive unit cell. Do you want it to include the redundant edge and corner atoms? Yes, exactly. That is the common way to display a ‘filled unit cell’. I don’t know of any software designed for crystal visualisation that would do it differently. Take CrystalMaker, Diamond 5, VESTA, Mercury, Materials Studio etc. The way Avogadro it handles is to fill a NaCl unit cell (depends of course on the space group) by 12.5 %, the remaining volume ist _empty_. If you look up pictures of unit cells in encyclopedias, crystallography text books, journals etc. usually the unit cell is actually really (completely) filled. If the cell is centered, like in the case of NaCl, I can imagine _some_ purposes for which you want so see the primtive cell, but I would rather go the other way round and would fill the whole unit cell as default (including redundant atoms) and include a command ‘Show Primitive cell’ and ‘Show Asymmetric Unit Only’ or something like that. > [@ghutchis](#): > > We can certainly add some command like “Fill Edges and Corners” or something.. Suggestions for wording would be helpful. In my humble opinion most of the users (crystallographers 😀 ) have a intuitive understanding that filling means actually filling completely. My suggestion is described in my last paragraph: - Fill the Unit Cell/Display Complete Unit Cell - Show Primtive Cell - Show Asymmetric Unit only > [@ghutchis](#): > > t takes any atoms outside of [0, 1] and wraps them into the base unit cell. Perhaps that’s a documentation thing, but I’m not sure why you think that isn’t working? Ok, I couldn’t have anticipated that because in the NaCl case, there was nothing outside the cell, so that nothing happened, except that bonds were generated (why is this the case?) Bond generation would be another topic 😀 Other topics are also some of the unit cell commands, but I will write some thoughts about these in the next few days. cheers Frank ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [January 27, 2026, 9:23pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/5 "2026-01-27T21:23:55Z")
We had this [discussion not too long ago.](https://discuss.avogadro.cc/t/unexpected-behavior-with-fill-unit-cell-command/6808/) The problem in some sense is the overlap in use cases. Yes, displaying unit cells typically shows all the edges. But someone who saves to VASP, etc. only wants the ~~primitive~~ conventional cell. Perhaps one suggestion might be: - “Fill ~~Primitive~~ Conventional Cell” (current behavior) - “Complete Unit Cell” or “Fill Complete Cell” (get all the edges and corners) The only downside is that if I add new strings now, there’s basically no time for translators to get them before 06-Feb. This has come up a few times - the code is easy, it’s more of a question for the interface. > [@anon86203829](#): > > except that bonds were generated (why is this the case?) Good question, I don’t know at the moment. As I said.. suggestions are always welcome. 🙂 ---
**Author:** ![anon86203829](https://discuss.avogadro.cc/letter_avatar_proxy/v4/letter/a/77aa72/32.png) [@anon86203829](https://discuss.avogadro.cc/u/anon86203829)\ **Post date:** [January 27, 2026, 10:22pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/6 "2026-01-27T22:22:42Z")
> [@ghutchis](#): > > I’m not sure what you want it to do. That’s the primitive unit cell. I forgot something. Maybe it’s not important, but if you write that the primitive cell view was implemented to transfer it to quantum chemistry applications, then maybe it is important after all: From a crystallographic point of view, this is not a primitive unit cell (UC), because a cubic face-centred UC never results in a cubic primitive UC. The primitive UC in this case is a rhombohedron with an opening angle of alpha = beta = gamma = 60°. I don’t know how VASP etc. operates, maybe this ‘primtive UC’ as Avogadro handles it is exactly what VASP needs as input, but as I said, from a crystallographic point of view it is wrong to name this a primtive UC. best regards Frank ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [January 27, 2026, 10:28pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/7 "2026-01-27T22:28:02Z")
Sorry, I typed too quickly - I meant a conventional cell, not primitive. You can convert between the conventional (i.e., all symmetric positions are filled) and primitive, etc. But DFT codes like VASP expect all the symmetric atoms be present but get upset when the atoms on the edges and corners are there. As I said, I’m fine introducing different commands if it’s clear what each will do. ---
**Author:** ![anon86203829](https://discuss.avogadro.cc/letter_avatar_proxy/v4/letter/a/77aa72/32.png) [@anon86203829](https://discuss.avogadro.cc/u/anon86203829)\ **Post date:** [January 27, 2026, 10:43pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/8 "2026-01-27T22:43:38Z")
Hmm, this 1/8 ‘filled’ cell is neither a primtive nor a conventional cell, because the conventional cell is the case of NaCl the face-centered one. So for me, the question is indeed: what does the command do? \*Maybe the command should read as ‘Preparing the Unit Cell for solid-state quantum chemical calculations’? ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [January 27, 2026, 10:52pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/9 "2026-01-27T22:52:12Z")
> [@anon86203829](#): > > because the conventional cell is the case of NaCl the face-centered one. This is _exactly_ that. It’s just not showing the translationally-equivalent atoms. You’re asking for a conventional cell with atoms on all the edges and corners even though some of them are translationally equivalent. ---
**Author:** ![anon86203829](https://discuss.avogadro.cc/letter_avatar_proxy/v4/letter/a/77aa72/32.png) [@anon86203829](https://discuss.avogadro.cc/u/anon86203829)\ **Post date:** [January 27, 2026, 11:13pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/10 "2026-01-27T23:13:54Z")
Yes, that’s what I’m (and I guess a not too little part of the crystallographic community) asking for. You can of course ignore that but then Avo2 will not be the tool of choice for crystallographers. That’s completely ok. 😀 The wording of the command as it is, is counterintuitive and what Avo2 does is, in my opinion, anti-crystallographically. If the crystallographic section of Avo2 is only for preparing input files for other programs, I can live with that. But even at the risk of repeating myself, I would find it very unfortunate, if you can’t even make a proper image of a completely filled unit cell of NaCl that you can put for example on your website, make contributions to Wikipedia etc. Maybe we are from very different communities, but can you show me one example in which the fameous NaCl structure is shown like the way Avo2 does show it after the command in question? I have been involved in crystallography intensively for 15 years and saw this type of representation for the very first time in Avo2. kind regards Frank ---
**Author:** ![anon86203829](https://discuss.avogadro.cc/letter_avatar_proxy/v4/letter/a/77aa72/32.png) [@anon86203829](https://discuss.avogadro.cc/u/anon86203829)\ **Post date:** [January 27, 2026, 11:16pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/11 "2026-01-27T23:16:14Z")
> [@ghutchis](#): > > You’re asking for a conventional cell with atoms on all the edges and corners even though some of them are translationally equivalent. Yes, of course, but if you want your point of view to be consistently represented, then – as Thomas has shown – you also have to display half, quarter and eighth atoms instead of the redundant other halves, quarters, eighths… ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [January 27, 2026, 11:35pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/12 "2026-01-27T23:35:01Z")
> [@anon86203829](#): > > The wording of the command as it is, is counterintuitive and what Avo2 does is, in my opinion, anti-crystallographically. Right. And I’m just trying to have a conversation about wording for different commands. Because Avogadro does serve multiple user communities. So we need to make it possible / easy to “fill” both with the translationally-equivalent copies that you want, as well as the “only symmetric positions, no translational duplicates” needed for DFT codes. I asked the same thing last year, which was _what is the most consistent wording_? I’m okay making “Fill Unit Cell” create the translational copies if that’s less confusing. I literally coded that for the little PNG graphics that go with the sample crystals. But then people complained that they had duplicate atoms in their DFT calculations. 🤷‍♂️ I’m rambling. Clearly two commands are needed, but I cannot come up with good wording: - Fill Equivalent Positions (no translational equivalents) - Fill Unit Cell (including translational copies) Other suggestions are certainly welcome. I’m happy if Avogadro has some use to crystallographers. ---
**Author:** ![anon86203829](https://discuss.avogadro.cc/letter_avatar_proxy/v4/letter/a/77aa72/32.png) [@anon86203829](https://discuss.avogadro.cc/u/anon86203829)\ **Post date:** [January 27, 2026, 11:45pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/13 "2026-01-27T23:45:52Z")
I can imagine that this is hard (neither I want to be a software developer nor a GUI designer 🙂 )… Maybe the commands are too long then, but my choice would be - Fill Unit Cell w/o Translational Equivalents - Fill Unit Cell Completely Good Night (it’s almost 1 o’clock in the morning in Germany) ---
**Author:** ![brockdyer03](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/brockdyer03/32/2015_2.png) [@brockdyer03](https://discuss.avogadro.cc/u/brockdyer03)\ **Post date:** [January 28, 2026, 1:19am UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/14 "2026-01-28T01:19:43Z")
> [@kohaerenz](#): > > Maybe the commands are too long then, but my choice would be > > - Fill Unit Cell w/o Translational Equivalents > - Fill Unit Cell Completely Perhaps following the convention in another program [like XCrysDen](http://www.xcrysden.org/doc/menus.html# __toc__ 37) would be good. The documentation there lists two (relevant) commands in the “Display” menu: - Unit Cell (with all atoms shown, including periodic replicas) - Translational Asymmetric Unit Cell (without periodic replicas, as something like Quantum ESPRESSO would use in an input) I personally think these are good, if a bit wordy. I think I have access to Vesta through my work, so I can check at some point what their syntax is for that. > [@ghutchis](#): > > The catch of course with that is exporting to other formats (e.g., calculations) in which primitive is needed and the edge and corner atoms are duplicates. This is something that makes the whole problem very tricky. Once you start needing to export a crystal to a file type, Avogadro needs to be able to know exactly what the user wants to export. I personally am in favor of Avogadro _only_ ever exporting a periodic version of a cell, and not a “full” cell. The periodic version is easily the more universal format, and is far more likely to be readable by another program. It also has the added benefit of not specifying redundant atoms, therefore reducing file sizes. I think that I generally agree with @kohaerenz on what Avogadro should display, but I also think that it can introduce some unexpected behavior for users who aren’t intimately familiar with crystallography and condensed matter programs. ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [January 28, 2026, 1:42am UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/15 "2026-01-28T01:42:31Z")
> [@anon86203829](#): > > - Fill Unit Cell w/o Translational Equivalents > - Fill Unit Cell Completely For the moment, I’m going with: - “Fill Unit Cell” (previous behavior) - “Fill Cell Completely” (adds everything) I can also add tooltips, which might be useful for some of these? > [@brockdyer03](#): > > I have access to Vesta through my work, so I can check at some point what their syntax is for that. I’d be curious certainly. I’m happy to make “Fill Unit Cell” the complete version if someone can come up with better wording for the “Fill without translational equivalents” Maybe “ **Fill Translational Unit** ”? I started a pull request, which also adds a way to filter and search the space groups (which has bothered me for a while). I’ll think a bit more about the heuristics when importing a CIF. [Tweak the "Fill Unit Cell" and add "Fill Translational Cell" for DFT packages by ghutchis · Pull Request #2571 · OpenChemistry/avogadrolibs · GitHub](https://github.com/OpenChemistry/avogadrolibs/pull/2571) ---
**Author:** ![matterhorn103](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/matterhorn103/32/1751_2.png) [@matterhorn103](https://discuss.avogadro.cc/u/matterhorn103)\ **Post date:** [January 28, 2026, 3:47am UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/16 "2026-01-28T03:47:56Z")
As well as the two options for treatment of edge atoms discussed so far: 1. Show only the original atoms 2. Automatically duplicate the edge atoms so that they appear at the other edges, thereby changing the coordinates list/file As I’ve mentioned in the past, I feel that there’s a third option too: 1. Show the implied atoms at the other edges without actually adding them For what it’s worth, I think that would provide the nicest and most intuitive UI. It can then function as a viewing mode as opposed to a command that permanently changes the file contents. What I mean is a mode where atoms on the edges are shown repeatedly but where the duplicate atoms are not actually added to the coordinates list, and all atoms that are actually the same atom behave as one e.g. changing the element of any of them changes the element of the actual true atom. As in, the atom exists once but appears in multiple places at the same time. In a really ideal world the atoms would just wrap so that half the atom was on one side and half on the other, but it’s been discussed previously why that’s a challenge. I think it would work fine without that anyway though, just by displaying whole atoms. ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [January 28, 2026, 4:51am UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/17 "2026-01-28T04:51:29Z")
> [@matterhorn103](#): > > For what it’s worth, I think that would provide the nicest and most intuitive UI. It can then function as a viewing mode as opposed to a command that permanently changes the file contents. Except the current rendering system is heavily optimized to show things that are actual atoms. That’s why, for example, it’s currently a pain to show extra unit cells without generating a unit cell. It’s a nice feature request (i.e., show things that aren’t actual atoms) but it’s not something I can get to anytime soon. ---
**Author:** ![matterhorn103](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/matterhorn103/32/1751_2.png) [@matterhorn103](https://discuss.avogadro.cc/u/matterhorn103)\ **Post date:** [January 28, 2026, 1:11pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/18 "2026-01-28T13:11:58Z")
Yeah, fair. Partly I guess I’m saying it in support of you/the current default being correct. In fact, I would argue against ever adding extra atoms automatically, even based on heuristics, if those atoms aren’t just fictitious reflections like the ones I described but are actually “proper”, independent atoms. I think it’d be more confusing if simply opening a file and then saving it would result in additional atoms being created without a explicit request by the user to do so. And like you said, it could cause a problem for some consumers of generated files. So, given the technical challenges you mentioned that mean that any extra added atoms must for now be “proper” ones, I’d be more in favour of just making it as easy and as obvious as possible for the user to add (and remove?) the extra atoms to get the three different patterns/styles of cell that are wanted (primitive, conventional, and with duplicated edge atoms). For a start that means coming up with really clear descriptions for the commands, because clearly they’re a bit lacking and prone to being misunderstood right now, but I don’t have good suggestions I’m afraid. I think the most that I’d find sensible in terms of “automatic” filling of the cell would be a dialog that pops up when a crystal structure is opened asking which representation the user wants. If that would be too confusing for students/non-crystallographers, a brief recommendation could be made in the dialog for whatever is deemed most intuitive. If that would be annoying for people who work regularly with repeating structures then there could be an option to save the preference. Basically I, like you, have some qualms about adding atoms that aren’t in the original file. ---
**Author:** ![anon86203829](https://discuss.avogadro.cc/letter_avatar_proxy/v4/letter/a/77aa72/32.png) [@anon86203829](https://discuss.avogadro.cc/u/anon86203829)\ **Post date:** [January 28, 2026, 5:58pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/19 "2026-01-28T17:58:09Z")
I think I’ll slowly say goodbye to this thread, I can’t contribute much more, but I still have one question: What do you mean by ‘adding atoms that aren’t in the original file’? In the CIF of NaCl, there are only _two_ atoms specified, the asymmetric unit. _All_ other positions in the cell are generated by the symmetry operations of the space group. Also the positions that the command ‘Fill Unit Cell…’ generates. Where is the difference then? Why do you allow symmetry operations that are not pure translations to add atoms but not translational equivalents? From a crystallographic point of view there is no difference between these two kinds of symmetry operations, and and it could be that our dialogue suffers a little from the fact that I argue crystallographically, while the programme performs specific tasks, e.g., creating “unit cells” that are _neither primitive nor filled conventional_, but are suitable for quantum chemistry programmes. best wishes Frank ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [January 28, 2026, 6:31pm UTC](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287/20 "2026-01-28T18:31:42Z")
> [@anon86203829](#): > > while the programme performs specific tasks I think that’s the take-home message. You’re saying as a crystallographer that you want to see all the positions, including translationally equivalent ones. Other users want “all the symmetric positions, but not the translationally equivalent ones” I have a patch that adds both “fill” options as well as a heuristic when opening files: - Fill Unit Cell (all positions) - Fill Translational Unit (no translationally equivalent ones) It also cleans up space group symbols, although getting the overline is driving me nuts. (Seems like Apple doesn’t include e.g. \overline{3} in their fonts. 🤷‍♂️ Yes, it would be nice to have “render in extra positions” as a feature or showing clipped spheres, but those are a longer-term feature request. (Same with ellipsoids.) [Next page](https://discuss.avogadro.cc/t/cif-handling-should-be-optimized-i/7287.md?page=2)